At the Flatiron school, every project went through the same process: use rails to create a REST API and create a separate repo for you front end (in vanilla JS or React), which makes sense with the MVC design pattern.
But as I sat at my computer (finally back in working order) today, I've found myself unable to kickoff my first Node.js project. Not only do I not have rails new to get things started, but I have absolutely no idea of how to start the project. This made me start questioning how I've been doing things all along.
To offer some background, I want to create a Pomodoro single page application similar to the Marinara Chrome extension, which I currently use. This project would use vanilla JS, Postgres (if hosting on Heroku), Node.js/Express.
As I mentioned the Flatiron way would be to:
- create 2 repos- frontend and backend
- set up the backend as a REST API for CRUD actions
- use the Fetch API to connect your frontend to your backend
Considering this isn't a CRUD app, is creating my backend as an API still the best approach? Aside from MVC, how would you structure a relatively small project like this? I've read into other design patterns, but still unsure.
Top comments (14)
Something like this really doesn't need an external data storage. Personally, I'd be trying to make it as local as possible & take advantage of local storage options. IndexDB, SQLite, Chrome.storage, the filesystem API, etc. This sounds like something that could probably be stored in a flat file format pretty easily.
I think the same, give a try with pure react and localstorage, or even sqlite as he says, that should give you enough for this kind of project.
Thanks for the feedback! To start, I want to build this as a fullstack single page app. Would this still apply? I updated the post to reference this
Depends on how sensitive you think your users would be to the data potentially seemingly randomly disappearing (Should be a rare occurrence, but more likely then not). If they are sensitive to it, then I would set up an extremely basic REST API to handle it. If they're not, IndexDB is a decent solution. IndexDB functions a lot like localStorage. They both can be cleared if the browser decides it needs that storage for something else. It can also be cleared by the user. The user wouldn't necessarily know that clearing it also clears your app's data.
I'm pretty sure there are libraries for IndexDB to interact with the major frameworks' state management libraries (Storing the stuff inside the state manager in IndexDB).
Thank you! i'll check out IndexDB
Well, every frontend needs storage and a way to interact with that storage. That said:
I believe that @zakwillis is correct.
In addition I would add that regardless how you interact with your data, the result will be an API. It may not manage a webservice, but will still be an API.
Hi, I think that whilst we have very different angles of attack - we agree.
Awesome.
I think creating a simple non CRUD app with static content is better structured without a backend API. If you can structure everything on the frontend you can make your app smaller and perhaps more performant and easier to deploy.
I have seen this frontend/backend API paradigm done on every project and it does not make sense to me for simple static apps.
Try option of Contentful api to serve data over node to your front end react app. then you don't have to worry about db specific stuff. Use contentful api as your data source .....play around contentful its niche.
My $.02, start with a microservices design first for all new projects. Think of ways to divide up many services into functional backend requirements.
Now I'm your case ask, what backend services do I need?
It sounds like the only service you need is something to service static web content. For that, you can just use azure storage, or nginx. This will perform better than rails or node or even .net core for static (unchanging, like spa js and html) content.
Now if you need to do backend processing for persistence, you can add that later, and your architecture hasn't fundamentally changed. Each new distinct functionality you can decide how to implement. Your APIs can be 0-unlimited, growing as your demands require.
The reason you are struggling is because you are trying to fit the technology to the problem. I think you are thinking - I want to learn this technology, now I have thought up a requirement, I can now do this technology.
The problem with this framework based approach, is once you get into the solution, you may come up with a completely different strategy. Then the panic sets in that you aren't perfect and the whole experience just sucks.
I read Eric Evan's book on Domain Driven Design and thought, now I can move all the database code out to another layer, create domains and bounded contexts. Before you know it, you realise that it was easier the old way - that DDD is pretty much like logical models within a database. Eventually, it became a hybrid approach that wasn't really DDD at all but with a better application layer.
The way I approach these sorts of things is;
1 - I have these pain points or requirements.
2 - What technologies do I already know that may help?
3 - If my existing knowledge is not sufficient, what other technologies are there which may help?
4 - Start prototyping, designing, learning, thinking.
5 - Commit to an approach, I am fairly confident will work.
I am very keen to start using Svelte on my projects, as I didn't see the appeal of Angular or React - but, until I really see a planned use case for it, I won't commit to it.
To answer your question - despite what everybody else will probably say. Start with a data model. Keep testing the model, thinking, can this structure hold this data, if a user does this, can it help with this? Once you have that in place, you have all the objects where you think you need them, it gets you thinking about the solution.
You mentioned CRUD. Again, see how you are falling into the trap of thinking, it must be restful > I need to perform all actions on all data, all actions must be exposed or it won't be restful. Data just doesn't work like that. The idea an entire model can be exposed with Create, Read, Update, Delete is naive. There is Event Sourcing, which is very interesting and great for storing history - but not so good for reporting. There is also CQRS.
No unless they plan on selling their user data or open source reasons
Thanks, Diane! To start, I would like to build this as a single page application first. What would be the best way to handle storage?
If you need to handle storage for just the user on the device, you can use JavaScript localStorage. It is built in to every browser and is easy to use.
If you need to share data between users then you will need to use something that runs not on the users device. This could be an API, or a cloud solution like Firebase or AWS. Firebase is pretty easy to use.