re: Frustration learning MERN from LAMP VIEW POST


Been there, done that (15 years here, same dev roots).

I'd say instead of comparing both from your LAMP perspective, invest some time in learning and experimenting with the tools you dislike of have not used, and as you probably already learned on your 16 year trip, the more tools you know the better you are at your job.

MongoDB is useful if you are working with JSON and if there is no need for relations (or there is really no concert about a bit of data duplication). Instead of relations, all documents are self contained, say you have a blog, then all comments from a post are inside the post itself. Also, MongoDB has some powerful aggregation functions.

Even though Express is nice for Web apps and APIs, I am not fan of it because it comes with A LOT of dependencies you are not using most of the time. I try to avoid it as much as possible, and since most of the things I do with Node are REST APIs I tend to favor Restify over Express. It is a shame though that Node's web server capabilities are so low level.

One of the biggest issues you face when coming from PHP into Node (or Ruby, or Python, or Go, or...) is that it PHP is not a long running process. The request is received by another process, handed down to PHP, and the response is then returned. With most of other languages, the process is long running and most times the code serves as both your logic and your web server (I am no fan of this btw).

As SaaS is high value task building a user authentication system with a few different tiers is always a good start and in LAMP this would be as simple as copy a few lines of code from my latest project, $_SESSION=['PAID'] and off to the races.

In MERN basically everything is stored in the browser so you need JWT to authenticate anything stored in the server-side database that is protected. This is frying my brain going through all the different methods. The moment your API key makes it way to the browser its game over so my guess is Node renders a token into the session... Don't want to pass it to a 3rd party to handle authentication, simple email and password is the goal.

I do not feel this is a fair and/or completely accurate statement. PHP's Session is also stored on a Cookie on the browser which would be the equivalent of using a JWT with any technology (PHP included). In general when writing an API, it does not matter what language or technology you are using, it must be stateless which means you need a token to identify who (or what) is sending a request. Also, a JWT is not a simple random string, it is signed, can contain extra (non sensitive) data, and can even be encrypted, reducing the amount of queries you need to do to identify your user or to display basic details.


Thanks for the comment, stateless concept I will look into more. Think I have the basic concept.

Client sends username + password to /user, server response HTTP 200 + JWT.
Cliend sends GET/POST/PUT/DELETE to /route + JWT, server response HTTP 200 + results.

My next project is to build a PHPmyAdmin inspired way to, as automatically as possible and without coding, turn the SQL database form an existing PHP project into a JWT protected REST API for each user with say 7 different roles (trial, basic, advanced, paymentpending, admin, test, public).
Best example so far has been neoan3.rocks/

Wish me luck! :D

Code of Conduct Report abuse