I need to create authentication with reactjs and node/express. Previously I did that with redux and right now I am not up-to-date with react-hooks.I saw somewhere in article that this can replace redux.This is little confusing for me, so I need good suggestion about this, and if you can share some article or example of react(updated) node/express authentication,then please share.
Thanks for attention to my wired question))))))
It really depends on what you want to do with your app. When you deal with more complex logic or flows in your application, I personally prefer Redux for making the code cleaner and easier to manage. If it's a simpler flow application, you can definitely leverage on hooks and context to create your own state management as good as Redux.
However, if the application ever has the potential to grow into a complex app (like requires middleware, debugging tools, etc.) I'd recommend starting with Redux so you don't have to switch from hooks into Redux later.
First, understand what Redux offers (and how it helps in a complex app):
https://redux.js.org/
Some related good articles as requested, if you want to build your own redux-hooks:
https://blog.logrocket.com/use-hooks-and-context-not-react-and-redux/
https://gorillalogic.com/blog/how-to-build-your-own-redux-state-management-implementation-based-on-hooks/
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'm wondering if some of you veterans could provide some guidance to some of us noobs.
Is there any advantage to writing vanilla Node over using Express? More specifically, any particular scenario where using Express will not be an option? And lastly for the tasks that you can use Express for, how deep should you go within the layers of abstraction to find out what's going on?
I mean there are plenty of people who can create robust and powerful web applications and they have no clue what the hell Express is actually doing for them.
Much appreciated
If I were you, I'd use express.
To be honest, Express isn't much of a web framework. It's really barebones, and barely adds any functionality on top of Node core.
With this said, however, there are some benefits:
For better or worse, express has become the 'defacto' default web framework for Node developers. There's a lot of information about it.
Express provides some core things that are useful: a routing layer (to map functions to URLs), an 'application' object that you can bind variables to for settings, etc. -- and a simple middleware model that lets you add functionality to your app easily.
Because express is so close to 'barebones' node, you can still write raw node code to work with it. It isn't at all complicated like other 'larger' frameworks: django, rails, etc.
There are a TON of third-party express middlewares you can use which add all sorts of functionality to your site. This makes building your site easier.
Finally -- the biggest reason to use express is that it does almost nothing. It isn't significantly different from using raw node except that it provides some simple abstractions over lower level stuff.
Because express is so simple, it means you don't need to learn much to use it, and can write your app in whatever way you want (it doesn't enforce any sort of patterns).
I'd like to add a few things here that might help you out. One thing that I have come to realize with software engineering is that there is never a "catch all" answer to a lot of these types of questions. Since each application is different, it is a good idea to look at the challenges and figure out what is the best tool for the job.
If you look at some of the performance tests done on the frameworks you notice that vanilla node is ultra performant. But most of the time your application isn't going to need to handle 8000 requests per second, and even if it does you can always scale your server horizontally nowadays. So you trade off a little bit of speed to gain a few benefits, such as:
Much easier to write.
The code base, in my opinion, is much easier to maintain.
A lot of the little gotchas are taken care of by the framework so you don't have to be a Node.js god.
Middleware.
Now, that doesn't mean that every single application should use express. A lot do because it is about as barebones as it gets. For instance, Walmart created Hapi because they claim that it is easier to maintain their code base with a 'configuration first' approach. So maybe if you are going to have this monster backend and a monster team, Hapi might be a good choice. If implementing something with real-time you might want to use something like socketcluster.io to help you scale websockets. It is all about picking the right tool for the right job.
That being said, there are advantages to building a server with vanilla Node, especially when learning to develop node apps. Since frameworks abstract a lot of the lower level stuff it takes away the opportunity to pick up some cool node tricks here or there. Or a lot of times if a framework is insufficient or an npm package is doing something weird it is good to have that knowledge of vanilla node under your belt to really understand what is going on. Having the skill of knowing how Node.js works is such a benefit when working with any framework.
First of all, I have seen this question: How to best create a RESTful API in Node.js and it has pointed me towards mers, which has been a great help.
But I have also been reading a lot of good things about derbyjs and it does look really interesting.
So my questions, does it make sense to use derbyjs for ceating a REST API (real-time features might be useful in the future, but not a 100% certain at this pont.)? And is it any better or worse than mers?
I am really grateful for any help.
Edit:
If anyone is interested, decided now to use sails.js: http://sailsjs.org/
The strength of Derby is that the same views (i.e. rendering templates into HTML) can be executed on the client as well as on the server. So for building a webapp, you won't have to explicitly code a REST API and then use it from the client-side JavaScript, instead you just write your views and Derby does the rest.
So if you're looking into making a REST API only (as your question states) and no HTML, there is no advantage in using Derby. It's the wrong tool for the job.
It depends on what you're looking for exactly. Derby.js is built on top of Express.js which has excellent support for creating a REST API. This also means that anything you can do in Express, you could also do in Derby. If you want real-time features, and the ability to build out a REST API, Derby.js is an excellent choice. It's also one of the reasons that people recommend Derby over something like Meteor (currently Meteor does not have support for REST endpoints, but it will hopefully in the future so also something you might want to keep your eye on, if you're in the market for real-time framework). However, if you're not looking for a node framework with an emphasis on real-time functionality, Derby is not the right choice. I would however recommend looking into Express.js to build a REST API. We use it currently for that purpose and it works really well. There are also a number of libraries and packages that play nicely with Express, so in the future if your needs change, it's easy to find something that works well with Express.
Anyway, I would recommend checking out some basic tutorials for how to create a REST API in Express because once you're able to successfully do that, adding some of the real-time features of Derby.js is fairly straightforward.
Basic tutorial on creating a REST API in Express.
http://coenraets.org/blog/2012/10/creating-a-rest-api-using-node-js-express-and-mongodb/
I'm currently developing a community (like a lightweight "social network") for a limited (local) target.
This is the first project where SEO doesn't matter and where I can happily exclude no-js users. That's why I'm thinking to start the project over and write my first site that is completely build with Javascript and my first Node application for educational reasons.
Details so far:
Browser: jQuery, maybe JavaScriptMVC (there are some things I don't like about JavaScriptMVC (like the routes), maybe I write my own little MVC or do you know a better suited framework?)
Server: Node.JS, Express framework, (maybe socket.io or nowjs for further features)
I got a few questions so far. I know it's better to ask a single question but there are more or less connected:
Express looks really nice but I'm missing MVC. I couldn't find any project that implements mvc and is build on Express. Is there a reason for that? Routing is nice in Express but I need a way to spread code across multiple files (controllers would be the best way I guess, the application won't be small and I need it maintainable)
The application will be more or less completely based on AJAX (json) requests. Is Express the right framework for such applications, anyway? I think the best way to write this project is to expose a json REST api which can then be queried by the web application over AJAX and by a mobile device app (which I'm also going to write). In my opinion Express' route system is quite suited for REST. But feel free to recommend other frameworks.
Have you seen Swagger? An API server available in Node.js with an automated UI Generator.
(source: wordnik.com)
To answer your primary question, yes there are controllers in Express. They are more akin to Sinatra (express is modeled after Sinatra rather than Rails). By that I mean they are light-weight method mappings to routes you define.
Browser: jQuery, maybe JavaScriptMVC (there are some things I don't
like about JavaScriptMVC (like the routes), maybe I write my own
little MVC or do you know a better suited framework?
I'd go with spine.js or backbone.js personally.
Express looks really nice but I'm missing MVC. I couldn't find any
project that implements mvc and is build on Express. Is there a reason
for that? Routing is nice in Express but I need a way to spread code
across multiple files (controllers would be the best way I guess, the
application won't be small and I need it maintainable)
You can spread files out all you want. I answered this here.
The application will be more or less completely based on AJAX (json)
requests. Is Express the right framework for such applications,
anyway? I think the best way to write this project is to expose a json
REST api which can then be queried by the web application over AJAX
and by a mobile device app (which I'm also going to write). In my
opinion Express' route system is quite suited for REST. But feel free
to recommend other frameworks.
I haven't built a 1 page app yet in node but from what I can tell, almost everyone seems to be using socket.io with backbone. That's not to say you can't, just that you'll find more examples that way.
You could check out Sails. Its structure is based on Rails.