Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I would like to know if what I do is right or not, please. Given that I'm starting to have a lot of collections in my root folder, I start to change the architecture of my database:
Instead of something like that:
|_ users
|_ workouts
|_ marketplaceVendors
|_ marketplaceProducts
|_ marketplaceCoupons
Something like that:
|_ users
|_ workouts
|_ marketplace
|_ data
|_ vendors
|_ products
|_ coupons
Is it bad practice or is it totally okay?
I would like to know if what I do is right or not
There is no "perfect", "the best" or "the correct" solution for structuring a Cloud Firestore database. We are usually structuring a Firestore database according to the queries that we intend to perform. So you should use an architecture and build the structure of your app according to your particular use case. So if you have a clear picture of what the queries should be, then building the database schema might be very easy.
There is nothing wrong with using those 5 top-level collections, as it's also nothing wrong with nesting those 3 collections under a "data" document. Please also note that according to Firestore quotas:
Maximum depth of subcollections: 100
So in my opinion, you can go ahead with any of those schemas, as long as you get the desired results.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 months ago.
Improve this question
I need a little advice before I start work.
So I have been developing a site under React for a client for 2 years now.
My client wants to duplicate this site to create 3 additional brands, the architecture, the design is the same, just the content and the logos change.
So for you is this:
1 - I duplicate in several github repos
Where
2 - I simply create several branches
Thanks
It really depends.
Option A, copy-paste your project to X other projects will make it easy to start and you can finish it in a day, BUT... every time you'll have to fix a bug you will need to do it in each repo and they'll diverge.
Option B, is to build front-end and an API.
The UI will be the same for all the projects but the API will return different data based on the client.
Option C, create a configuration file that you can modify based on the customer.
I believe that Option A will be the simplest & fastest one to get started with. You'll pay the price as you grow, but if you don't need to maintain the projects in the future I would go with it.
If you're going to maintain those projects for a long time you might want to consider refactoring the projects to a dynamic backend that returns the data based on the client.
Option C, it's a pretty good compromise between A and B.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I have a React project with many modules. Is hosting it separately or together better? I have searched on the web for opinions but I don't get a proper answer.
why do we go separate host cost and any other things high when you go to a separate one. modules and project put it together. when you hosted in separate if one module was missing all projects was going down.put it together and host it will be easy and saving costs.
To a certain point, it should be ok to host them in one piece. But when your application grows and you have loads of third-party libraries in use it might effect the performance of your app. So in this case I think it will be just fine to host them in one bundle.
https://reactjs.org/docs/code-splitting.html
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I'm currently developing a side-project and trying to learn some general API things.
The user can access a list of projects by going to /projects and I'll get
all of the projects as a list. The user can also click an Edit button that goes to
edit/{project_id} and was wondering whether I should pass the project object to the component or just do a separate request to the API with the ID of the project to only get that project.
The first one is good because it's easier and also, I won't have to send all information about the project objects because I can't show all of them in the table (in /project) and this will save some data (ex. the list will show name of project and created date only). However, the second way is good because there will be less requests to the server.
My question here is, what is the preferred way?
Sidenote: I've tried searching for a question like this but didn't know how to phrase it, so this might be a duplicate.
In this situation, I would advocate for the separate API request. With a list of projects, you really don't want to include everything in your "get all" API call; just enough basic stuff to populate the list. That will make your queries faster and data transfers smaller, which is especially helpful when a large number of projects come into play. However, when you "deep dive" into a single project, then you'll want everything about that single project.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
This question is a little more generic, a brainstorm one. I'm about to develop a small website, and I still don't know if it’s better for me to store my “Text” (to fill Labels, Messages, etc) data on the Database or just on the frontend.
I know that for a fact, consulting the BackEnd Database is slower than just searching a specific file, but it’s also better to update the list later-on (when the website is developed) by just running a script.
I want to know some opinions, experiences, advantages and disadvantages about both.
Edit: For the technologies, i was thinking in using ExtJS with a Java Backend, I'm not quite sure about the BD yet.
Consider what data you are storing and the purpose of your website.
Advantages of front end storage: quicker
Advantages of database storage: more secure/structured
If your strings are sensitive then I would secure them in your database. Any client information, including "Text" data should be stored on the back end. If the strings are only relevant to you as the site owner then I don't see a problem with storing them on the front end.
Also perhaps specify which technologies you are using to build this site to get more specific responses.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Hi in simple terms have a company listing website.
I have a database of companies people can search and results are shown - fine.
Now what I want to do is open my database or these database driven pages to google so they can be indexed - so in an ideal world if someone searches for 'xyz company' their profile on my company listing website could be dispalyed in the search results.
As these pages wont all have direct links to them how can I get google to spider them?
Thanks!
EDIT***
OK to clarify they will be accessible by links ie "site.com/company?id=1" maybe even seo friendly urls if I can sort out dupe company name issues. It was more that the actual links wont all be listed on the site but now as others have suggested I can return all of these to a sitemap.xml but as per BiAiB's comment Google sounds like it will cap the number they will index...
I like the idea of a company by county page though that would work with direct links.
You should make an XML sitemap, then submit it to Google Webmaster Tools.
Google have a page about it here: http://support.google.com/webmasters/bin/answer.py?hl=en&answer=156184
Another way would be to make an HTML sitemap that contains all the pages, and have a link to it in the footer. Without any links to the content, Google will likely not think it's very important, and won't give it high rankings.
Your ideal solution is to create a contextual link structure to all your businesses.
This not only lets Google find your businesses but also helps Google categorise them.
It would probably also help your visitors.