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.
Related
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.
I have built a Rest-API with Express and mongoose, now it's time to connect it to a Frontend and I am bit confused, I have started building the Frontend of the app with hbs as the templating engine and that works well but I was also considering React for example and that brings me to my question.
What is the best solution here? to build the whole App in one folder so to speak, with a templating engine taking care of the Frontend or to create the API, host it and then use it with a Frontend application? It is a matter of preference or one is better than the other?
This really is a matter of preference. There are many benefits and trade-offs for each method. Here are some:
API with Single-Page Application
Benefits
Easier to make a more dynamic app
With an API you can allow third-parties to integrate with your app easily
Fast - after the app has been initially downloaded only data needs to be transferred!
API and frontend separation can help keep business logic in one place (on the backend)
Offline and caching are easy!
Downsides
SEO isn't as easy (but still very much possible)
Slow - if your app is big, the initial download speed can be slow (there are lots of solutions for this)
Multi-Page Application
Benefits
Fast (page download can be faster)
SEO is slightly easier
More secure by default (due to cross-site scripting on SPAs)
Downsides
Slow - unlike a SPA, you have to download every page
Harder to build and debug
This is by no means a comprehensive list of trade-offs but hopefully, it will help you make an informed decision. Personally, I prefer the SPA approach because I have multiple sites/apps using one backend as well as the ease of development.
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
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 years ago.
Improve this question
I'm caught in a fix. I've learned ExpressJS to develop a web app and I'm a quarter of my way done. Then comes along Meteor which was very recently released. It has gotten a lot of press, funding and it has the benefit of being able to port to Cordova. Now I'm not sure whether to stick to ExpressJS or transition to Meteor.
Key Points: Scalability, Ease of use, Development efficiency
Express = MVC Framework built in Javascript and is powered by Node.
Meteor = Full Stack that has the front-end and back-end components to build a real-time application.
To create the same implementation of Meteor using Express, you need to look at the MEAN stack, which includes MongoDB, Express, AngularJS, and Node. You can create the same thing in Meteor that you can with the MEAN stack, you are just going to be doing a lot more learning especially with AngularJS. Express and Angular are taken care of in Meteor using Meteor's template system and Blaze.
I would stick with Meteor. It still has a few drawbacks, but there are workarounds. It's amazing what you can throw together in little time.
You're comparing oranges with potatoes. Expressjs is backend and Meteor is fullstack, such a comparison is unfair at all!
I've been working with Meteor since 0.8 and I suffered in the skin the pain of upgrading, removing old vital third party packages, etc. you get the idea. Although Meteor reached 1.0, I don't think that the mobile component is quite ready, check github issues on it.
I think Meteor is ready for building online platforms. If you find that it doesn't play well in the mobile, you can still maintain your Meteor application and create an API on top of it, you can find packages on atmospherejs.com for it (or even use iron:router). That's what you would with Expressjs: create an API to be used by mobile devices.
About your Key Points of Meteor: Scalability - It's possible to scale Meteor although you won't a good article about it but if you take a look at Kadira, Arunoda managed to scale it. Ease of use - It's fairly easy to write a Meteor application in the beginning but in the long run you'll face some problems like I faced. Development efficiency - My experience in team wasn't that positive, we had bad architectural design choices and some bugs because new developers (even experienced ones) don't get Meteor, example: Instead of using Collections allow and deny rules, they use Meteor.methods for everything which doesn't translate to security. Some even publish the entire database to the client and say: Works great on my localhost :D
About express: I have little experience on it but the comparing it with Meteor, it's not fair at all. Meteor doesn't not the same purpose as Expressjs.
A comparison with MEAN Stack would make much more sense: http://mean.io/
Express.js is quite different from Meteor.
Meteor tries to give a good framework for everyone taking a lot of decisions (hopefully good decisions) those are usually uninteresting from the application development point of view: what transport library to use, how to synchronize data, how to build a reusable API, security, CRUD operations with the database, etc.
Instead Meteor gives you a unified experience across the stack. Since it has so much power control over backend, transport, interfaces, front-end, build tool chain - it can build a lot of neat features those would be so much harder to glue together from Mongo+Express+your favorite front-end framework+socket.io+grunt/gulp.
Read Socket.io's creator's blog on how hard it is to deliver good user experience in single-paged apps these days: http://rauchg.com/2014/7-principles-of-rich-web-applications/. Meteor does a lot of it +more. (except for the server-side rendering and predictions, at least right now).
Think about how many security holes you will have if you pick the abstractions too low level in hope to implement everything right.
I've recently begun hearing a great deal about Node.js. While I understand a few things that it's able to do, namely create a web server, I'm wondering if you could provide me with a solid reasoning behind using this functionality in a production environment.
This article made a solid case for using Node.js as a development tool, essentially stating that it can provide the usability of a backend environment without needing backend experience. I've also heard of many developers using Node.js in production projects (Codepen for example), but I simply don't understand how it can be useful when there are established web servers out there such as a LAMP stack.
I would love to invest the time into learning about Node.js due to its growing popularity, but because I do have a fairly solid backend foundation, I'm curious if it's necessary.
In short, what are some of the most useful aspects of Node.js and why would someone need to use in a production environment?
Perhaps the best answers can come from large companies who are using Node successfully in production.
Why Walmart is using Node.js
How we build eBay's first Node.js application
How LinkedIn used Node.js and HTML5 to build a better, faster app
Scalability is often the big reason. End to end javascript is also a popular answer. Also Node is good at making some potentially complicated "real-time" scenarios almost trivial when using a library like socket.io.
And here is a list of companies using Node with a short blurb on what they use it for.
The main company behind Node.js, Joyent, is tackling this question head-on with their recent roadshow "Node on the Road". They have collected a number of interesting testimonials of why big companies (Dow Jones, Walmart, Yahoo, etc) are using node in production. Check out their videos section for more details.
At my company we use Node in production everywhere. We typically serve the static HTML and JS files using NGINX but smaller apps will use PM2, a Node process manager, to add clustering redundancy and auto restart to a project. PM2 documentation
Example of using PM2 to maximize clusters for your Node app:
pm2 start -i max myNodeServer.js