I'm working on an e-commerce website using the MERN stack, I'm about to start retrieving data from the db so I came with this question:
what is the best way to deal with dbs? do I have to keep fetching data each time the user switches from a category to another or just do it once and use it everywhere ?
I tried both but I would like to know others opinions.
I would say it depends on how you implement your e-commerce application.
If you are creating multiple pages of categories then on each page you would do a request. If its a single page application then you would need to get all of your information so that you can display it all when the user goes to that page. If that single page application has a really long page with lots of documents, then you could implement something like pagination or infinite scroll where you would call for more documents as needed.
It's really about how you set up your application. You most likely will make new calls when going to new pages, or one call on a single page with few documents. CRUD - create, read, update, destroy, will all need their own routes as well, which you will obviously call when needed. Although, those don't always have to be implemented on the frontend if you plan to maintain your application from the backend then you can of course tap into MongoDB through the shell.
Related
I'm trying to create CMS with MEAN stack. And I have a conceptional problem on very first fundamentals.
What is the best way to store page tree structure(parent pages and child pages) in MongoDB? I've read docs: https://docs.mongodb.org/manual/tutorial/model-tree-structures-with-parent-references/ but that way force me to search the DB recursively(so I need to forget about async). Is it the best way? Maybe I need to store pages ID in one of configuration files? Or maybe MongoDB isn't good for that kind of app?
I am working on an application which will have users.. who create posts.. and other users can like/comment on any post.
I am trying to figure out a best way to design db tables for this. I have read the anypics tutorial on parse.com site. They keep all comments and likes in a table called "Activity". (which makes sense) being able to query any type of activity (like/comment) from a separate table without having to touch "posts" table.
My question is- in this scenario how do I fetch all posts that current user created along with likes and comments on each those posts?
Anypic app by parse makes a separate request to fetch number of likes on each post (which I think is not ideal.) I am new to nosql data stores.. so if someone could help me out with suggestion on how to structure data that would be great.
Also, how bad is it to store all likes/comments as an array in the post itself? I think this won't scale but I might be wrong.
Thanks
In terms of Parse, I would use an afterSave Cloud Function to update the Post anytime a like/comment is added.
Have a look at the documentation here, in the most simple case you just create an afterSave for the Activity class that increments the like/comment count.
In a more advanced scenario you might want to handle update/delete too. E.g. if someone can change their 'like' to 'not like' you would need to look at the before/after value and increase/decrease the counter as needed.
I am a fan of storing extra 'redundant' data, and no-sql/document-db systems work well for that. This is based on the idea that writes are done infrequently compared to the number of reads, so doing some extra work during/after the write has less impact and makes the app work more smoothly.
I'm trying to model a simple, experimental app as I learn Symfony and Doctrine.
My data model requires some flexibility, so I'm currenty looking into the possibility of using either an EAV model, or document store in MongoDB.
Here's my basic requirements:
Users will be able to store and share their favourite things (TV prog, website, song etc).
The list of possible 'things' a user can store is unknown. For example, a user may want to store their favourite animal.
Users can share their favourite things with other users. However, a user can decide what he / she shares with each other user. For example, a user may share their favourite movie with one user, but not another.
A typical user will log in and view all the favourite things from their list of friends, depending on what his friends have decided to share. The user will also update their own favourite things, which will be reflected when each other users views their own profile. Finally, the user may change which of his friends can see what of his favourite thing.
I've worked a lot with Magento, which uses the EAV model extensively. However, I'm adding another layer of complexity by restricting which users can see what information.
I'm instantly drawn to MongoDB as the schemaless format gives me the flexibility I require. However, I'm not sure how easy (or efficient) it will be to access the data once it's saved. I'm also concerned about how changes to the data will be managed, e.g. a user changes their favourite film.
I'm hoping someone can point me in the right direction. This is purely a demo app I'm building to further my knowledge, but I'm treating it like a real-world app where data access times are super-important.
Modelling this kind of app in a traditional relational DB makes me sweat when I think about the crazy number of joins I'd need to get the data for one user.
Thanks for reading this far, and please let me know if I can provide anymore information.
Regards,
Fish
You need to choose a model based on how you need to access the data.
If you just need to filter out some values when viewing the user profile, a single document for each user would work quite well, with each favorite within that having a list of authorized user/group IDs that is applied in the application code. Both read and write are single operations on a known document in this case, so will be fast.
If you need views across multiple profiles though, your main document should probably be the favorite. You'll need to set up the right indexes, but performance shouldn't be a problem.
Actually, the permissions you describe don't add that much complexity to an EAV schema - as long as attributes can have multiple values the permissions list is just one more attribute.
I'm developing a site in Symfony, and I'm not sure what the best way is to handle this scenario.
I'm creating a party bookings system. Anyone can go to my frontend app and submit a new booking. Once they're finished, they'll just get a confirmation screen, they can't edit it. Easy.
Only certain users will be able to get to the admin app (it might be secured simply by being on an intranet, but that's not important, just assume it will be only accessible by admin users). They'll be able to view the list of submitted bookings. Easy.
My problem is around code re-use when allowing admin users to edit existing bookings. When you do generate-module in Symfony, the generated module (which as a newbie I'm assuming is a good example of structuring things) creates the form as a partial. I've had to customize this form a lot for my usage (lots of Javascript, etc), so of course I want to re-use this code, to be able to load an existing booking into this form. But there doesn't seem to be a way to share this partial between the apps (I've seen people mention making a plugin...but this seems complicated for this use).
I considered using an IFrame to load the form from the frontend and just passing an "id" parameter to load it in edit mode, but this would mean that the edit mode is not secure - anyone could go to the form on the frontend and pass this parameter to edit a booking.
I also considered putting all of the form display code (HTML, Javascript, etc) in a method on the form object, but this doesn't seem very MVC - all of the display code is then in the form. But this is only because I'm thinking of the form in the same way as a model - is that right?
I feel like this should be a common situation. You can share models and forms between apps, why can't you share this common form display code too?
Thanks!
You should reconsider having 2 applications in the first place. Not only you run into the code reuse problem, but also i18n, testings and other issues. I find it much easier to have 1 application with different bunch of modules for frontend and backend users. You can configure security per module. You can have one sign in form for all users and redirect them to appropriate module based on their credentials.
You can reuse partials between modules inside the same application, but you seem to be talking about two different applications (frontend and backend) so as far as i know the only way is to copy & paste the partial from one application to the other...
I am in the process of building a website content management system for one of my clients. It's a highly customized system, so I cannot use any "of the shelve" solution.
I need to allow my client to add pages to the website on the fly. I have two options here:
(1) Create a database driven page in the format of www.mycompany.com/page.aspx?catID=5&pageID=3 (query the database with the category and page ID's, grab the data and show it on the page) - or -
(2) Allow the management system to create static pages, something like www.mycompany.com/company/aboutus.aspx and www.mycompany.com/company/company_history.aspx , etc.
I believe that, while the former is much easier to implement, the latter is a better both for the user AND for Google.
My questions are (finally): (1) Would you agree that the latter is a better solution, and (2) What is the best way to implement such a solution? Should I create and update each file using the FileSystem (i.e. - the site's management system requires the user to supply a page/file name, page title and content, and creates the page on the fly based on these parameters)? Is there a better way?
Thank you!
It's entirely possible to have database driven pages with nice URLs. StackOverflow itself is a great example - this question's URL is http://stackoverflow.com/questions/1119274/adding-pages-on-the-fly-with-a-cms-system, but the page is built from the database, not static HTML.
I would use the first solution, but mask the addresses using a custom request handler. Basically, give each of your pages a unique string ID (such as about-us) and then, with your request handler that takes all requests, find this particular page in the database and render it.
See this article for some additional info (found it when googling for custom http handlers in ASP.NET.) In that article, it has the following handler added:
<add verb="*" path="*.piechart" type="PieChartHandler"/>
You would probably want to catch all paths (*), excluding certain media paths used for CSS, images and JavaScript.
More resources:
Custom HTTP Handler
HttpHandler in ASP.Net
I'd stay clear of static pages if I where you. Dynamic Data, MVC and some good planning should take you a long way!
What you need to do is to create some or many templates that each view/controller in mvc can use. Let whoever is responsible for the content handle it through dynamic data entities.
I would use the first idea, but work out a better URL scheme. If the system doesn't provide nice URLs (without ?), you'll have trouble getting the search engines to parse the whole site. Also using numbers instead of words make it hard on users to pass around URLs.
If you start to have performance problems you could add caching that would generate static pages from time to time. I would avoid doing that until you have to; caching can cause many headaches along the way to getting it right.
Although the existing advice is more-or-less sound, the commentators have failed to consider one factor which, admittedly, you haven't given much detail on. Are these pages that they'll edit once they're built, or a they one-shot creations? If the latter, your plan of generating static pages isn't quite so bad as they suggest. Why bother even having to think about database schemas and caching, when you can just serve flat content.
It will probably make for pretty lifeless, end-of-the-road pages, but if that's what you want ...