I have decided on a stack for a web app project. Its as follows.
Express JS + Knex + postgresql backend as a Web API layer.
VUE JS as the front end.
I have completed rough design of the whole system. I am stuck with the implementation part. Do I build the UI first and flesh out the API, or vice versa.
Usually you build both at the same time - preferably by two different teams to minimize tight coupling and leaky abstractions. Sometimes the API is build first and then the web or mobile or some other frontends are built for that. Sometimes a frontend is build first as if the API already existed and it results in a solid specification for the API to get built later. Sometimes the specification is created first and then both backend and frontend(s) are built to follow the spec. It all depends on the specific work style and requirements. It's more important how you to it than when.
I'm working alone on a personal project and my approach have been to work only at the frontend then mock the http part with a realistic mock that emulates a real api behaviour and only at the end moving at the api development.
I decided to use this apporach because in my experience no matter how the model and functional specifications are clear, they will always be subject to change request and you can prevent the side effects on your development workflow by testing and interacting with the actual UI.
Then you will find that the api developemnt will be completed in a matter of weeks not months with a better clear understanding of what are your (or your client's) needs.
Hope this could help you
Related
I wanted to start a full stack project, with all the tech stacks in the market i am confused to which one should i pick. I know reactjs in frontend, nodejs and a little bit of django in backend.
First should i use Reactjs or any other frontend framework which is a single page application so all the JS code will execute from frontend or should i use that or Nextjs which does the server side rendering so in the browser we reduce the execution of js. If i stick with Nextjs then suppose i wanted to create a mobile app for my project can i use the nextjs for that or should i shift the code entirely
2)Does backend language really matter, if matters which language should i use and If it doesn’t matter then in nodejs which server framework should i pick(ex: expressjs)
Should I go with server or serverless while creating the api then it does not matter with the framework(because lately I have seen many realtime apps backend code is entirely wrriten by serverless functions using cloud)
4)tell me some of the important things i should use in a realtime app like docker, Kubernetes, load balancer, and any other things you might think this should be present in the full stack app
if you know any blogs or articles about choosing the architecture for ur project comment down.
This is a very opinion and experience based question that cannot be answered as you are asking it (and is technically out of scope in stackoverflow). I will try to help as much as possible anyway.
In general many different stacks are viable and in order to be productive it is more important that you are experienced in what you decide to use. This is because most technologies have pitfalls that can only be avoided by knowing them / experience.
Besides the frontend technologies/frameworks you listed there are many others. Having some experience with React-Native as well, my personal current favorites would be Angular and Flutter (both Google technologies) for web/apps.
It does and it doesn't matter. Without knowing your specific requirements no recommendation can be given though. As a general hint I recommend to use a language that your developers love - There is usually a reason for it. See the 2021 Stackoverflow Developer Survey.
Server vs. Serverless is mostly a business decision and you have to model your costs including hosting / development / maintenance efforts vs. usage models. Another aspect in this decision is time-to-market pressure since Serverless may be a bit faster to finish in some scenarios.
This cannot be answered without knowing the details and requirements of your project. Recommendations could be from hosting a static single web page in a S3 bucket to running your own fleet of (cloud-)-bare-metal clusters or buying a supercomputer.
I am learning Node JS. It had almost learnt 70%. I am very interested in Backend Development but I'm not interested in Frontend development. My question is how do I practice my Node Skills. I only know HTML, CSS in Frontend. How can I make projects in Node JS without knowing Frontend? Or do I need to learn frontend frameworks such as React too to make projects.
You can build an API and use postman to make requests. Start with something simple and keep improving by refactoring your code.
You can work on the API creation part but in my opinion, you must learn one frontend framework it will not only increase your skill sets but also help you to coordinate with frontend easily and take more advantage of it than the projects you will build will be more useful and advanced as well.
You could also focus on implementing some algorithms and data structures starting of with simple ones such as LinkedLists, ArrayLists, sorting algorithms and then move on to (binary) trees and graphs.
These will be required for any programming language to solve (complex) problems and there are many books and internet resources for this. Just search for algorithms and data structures and you'll get plenty. You don't need more than a console application with some simple console.log() statements to implement algorithms - no need for fancy UI.
Last but not least, you should certainly have a look at TypeScript if you want to develop more complex backend applications.
If you really want to do Web Development though it is certainly helpful to have a basic understanding of frontend development or know the basics of common frameworks such as React, Vue, Angular or Svelte.
As others have mentioned for API development you could also just use Postman to send requests.
My team has developed an iOS and Android App for our project while we use node and socket.io for back-end. We want to move to meteor so we can have a front-end with Angular 2 easily connected with the back-end.
But we want to rewrite the back-end with Meteor so our Apps can use it. And after this create the front-end.
My question is easy, in Meteor front-end and back-end are done at the same time? Or can we first build the back-end and after this the front-end?
Yes, this is possible although it would feel a bit awkward to an experienced Meteor developer.
The Meteor "back-end" exposes the following:
managed collections: these are the definitions of the mongodb collections that will be used by your app to persist data. Note that some of these can be private to the back end, i.e. not exposed to the front end at all.
publications: these are the filtered/projected "views" of the collection data that the back-end will share with the front end on request (the form of the request is a subscription). Published data is synchronized bidirectionally with the front end asynchronously over WebSocket. This is the magic of Meteor's DDP which IMO is Meteor's core innovation.
methods: these follow a more traditional request-response pattern. You can have as many of these as you want and each can accept any number of parameters including objects. Meteor can also do latency compensation for methods which means that the method is first simulated on the client and the UI updated while waiting for the server to come back with an authoritative result. If the server result differs then the UI is patched up with the authoritative result. This makes database updates appear instantaneous to the user while providing eventual consistency.
If you like you can even build traditional REST endpoints with Meteor but then you would be missing out on the reactive sugar. These can of course be useful for other integrations however.
Like nodejs, Meteor encourages developers to tackle the full-stack. You're less likely to segregate developers into back-end and front-end functions which gives you a lot more flexibility.
We are going to build big social web app. We have to implements 2 big modules:
FrontEnd - single page app (Backbone.js)
CMS - system to manage contents of FrontEnd (daily content, sponsors, banners, links, special offers, upload media etcetc)
FrontEnd will use Node.js powered REST api which will use DB in the cloud (PG or Mongo - didnt decide yet).
My question is: should CMS also use same REST api as FrontEnd? Or should we make separate app (not node.js neccessery) for CMS that would "talk" with db in the cloud directly? My question arises because on previous project we had this issue:
Single REST api for FrontEnd and CMS.
When we wanted new functionality in CMS we had to implement it in RESTapi - and then we had to restart whole APP (RESTapi) which was problematic in production...
So:
Implement 2 RestApis - one for FrontEnd and one for BackEnd?
Implement 1 RestApi for FrontEnd and implemnt CMS as separate app talking directly to database?
How do you do it?
Out goal is to implement super-fast FrontEnd and Big/Heavy CMS (its is going to be bigger than FrontEnd). So we are thinking of completly separating CMS module from FrontEnd module. Eventual need for communication between modules would be implemented through redis pub/sub for example - What do you think?
Software architecture decisions are always very contextual - the people most qualified to make the call are you and your team, since you know way more than we do. That being said, based on the info you've shared, here are some things to consider:
Content Management as a problem space is pretty mature. Unless part of your revenue model involves innovations in how you handle Content Management, you would be unwise to build one. There are fantastic CMSes both open source and commercial, ranging in price from hundreds of dollars to hundreds of thousands. I cannot caution you strongly enough against the common developer fallacy to discount the value of our own time. Even if you spend an entire engineer's salary-worth on a CMS, you'll almost certainly come out ahead.
An architecture that uses a CMS should reflect the reality of #1, that CMSes are mature and stable. You want a strong and well-defined interface boundary between the parts of your system that are unique to you and specific to your revenue model, and the parts that are interchangeable with COTS (commercial off-the-shelf) - even if you do end up building it yourself (which again, I strongly caution against) - you'll run into impedance mismatch problems that are very hard to get out of and create friction to new feature delivery across the entire system if you design something as if it's bespoke when it's not (or vice versa).
I'm new to the full stack javascript application development, have read a lot of posts and documentation to all sorts of things but am a bit stuck on the following issue:
There are two frameworks that seem to offer quite similar functionality but are never contrasted against one another on the internet (as far as I could tell)
SailsJS - server side MVC framework built on Express
BreezeJS (+AngularJS) - client side MVC
Apparently I can combine Sails with Angular, there are a few attempt in NPM but none using Breeze in addition, is that due to redundancy or is it just a stupid idea?
I was thinking of developing a SPA that has computation intensive backend processes ( e.g. machine learning on large data sets ~ millions of mongo documents ) on something like
Mongo - Node : { Express - Sails } - Breeze - Angular
I'm looking for feedback on whether this kind of stack (particularly the Breeze / Sails part) is a bad idea or not. Also I'm really thankful for any advice / links to advice on javascript full stack architecture design decisions.
Thanks!
Basically, all the software you have mentioned can be used in one product. It's the important though to understand the purpose/strength of each component:
1. MongoDB
This one is pretty clear: database engine.
2. Node.js
This one too: server-side Javascript which will power your API.
3. Express.js
Now it's getting more interesting. Express is a server-side web-application framework for Node.js, but a very minimalistic one, which means it provides some basic functionality, no hidden magic and other fancy stuff.
4. Sails.js
On the contrary, Sails provides a lot of magic, starting with the API out of the box and ending with sockets. Even though it's built on top of Express, Sails is a server-side Javascript framework which follows a completely different approach, with convenience over simplicity. If we talking about a SPA, then the most useful thing Sails has to offer is, definitely, API out of the box: you'll be able to get it up and running in less then 5 minutes.
5. Angular.js
Here we are getting onto the client side. Angular helps you better organize your client-side Javascript and easily perform some pretty complex tasks in the browser. And, of course, Angular (or a similar framework, like Backbone, Ember, Knockout, etc.) is a must-have nowadays if we are talking about rich client applications.
6. Breeze.js
Finally, Breeze provides you with a way to organize / access data from your thick client Web application. Whether you are using Angular, Backbone or Knockout, Breeze will help you manage your data in a way similar to ORM / ActiveRecord concepts.
So, all these components can easily work together, no doubts (sometimes people are talking about MEAN, MEANS, BMEAN stacks, where every letter is a first letter in the name of a framework / component). But ultimately, it's up to you to decide how many of them you should use in your product. As an example of approach, you can start with Mongo / Node base, and then choose necessary frameworks by asking yourself for the each one, whether it simplifies your life (especially, long-term-wise) or complicates it.