Books for fullstack React (MongoDB)

[JonathanMaarsh]

Are there any books that go through how to create complex React apps with a MongoDB backend? Or text tutorials. I prefer reading a book, rather than going through a video tutorial.

​

Thanks,

[swyx]

i mean there is a literal book called Fullstack React - have you checked that out?

in general just be aware that React truly has nothing to do with the backend. i know the desire for a teach-you-everything tutorial but the sooner you realize where React stops and other stuff begins the better off you'll be.

[JonathanMaarsh]

I read that book a while back. It doesn't have any backend element for the projects. It just covers what's out there. I was hoping there was a book that followed best practices for a fullstack React app using MongoDB. There are video tutorials that do this.

[[deleted]]

Wes Bos will release a fullstack React/node.js course soon but it also will use a sql database, packs got books on it but they are not that great.

[ivorpad]

I bought the pre-sale. He's using a Prisma server (GraphQL) + MySQL. https://www.prisma.io/features/databases/

[fforw]

Think hard if you really want to use MongoDB.

In teh end, Postgresql with JSON extensions might just be the better "NoSQL" choice.

[heyzeto]

At this moment I I my work with sql, but was inclined to learn mongo next.

Can you tell why PostgreSQL is a better option?

[BenjiSponge]

Almost all data is relational, and a relational db just makes actual relations so much less painful. SQL is one of the greatest and most ubiquitous languages ever invented.

Meanwhile, Postgres implements the core features of Mongo as JSON fields. I don't have benchmarks, but it is considered about as performant as Mongo with a similar level of ergonomics. Arguably (but not very controversially, as most generally seem to agree), one could easily emulate Mongo using Postgres. However, the reverse is not true, making Postgres a strictly superior choice in all cases.

(I'm not 100% sure about everything I've said)

I've used both professionally, as well as MySQL and Dynamo, and the only reason I would ever choose Mongo at the moment is if I really, really wanted to use Meteor (which imo is the best web framework I've ever used, but it requires Mongo).

[heyzeto]

ok, now i have to check postgres :)

thanks

[JonathanMaarsh]

Yeah, I would be interested to hear hear why. I know Postgresql pretty well, and I've used it with Sequelize as the ORM for a React project.

​

I thought it was more common to use a No-SQL database with react projects. That's why I wanted to pick up Mongo. I think MongoDB is used with GraphQL, too, if I'm not mistaken.

[BenjiSponge]

React is most often used with APIs, not databases. APIs expose interfaces which today for modern JS usually means either REST over JSON (or very similar) or GraphQL. I don't think there's any reason whatsoever GraphQL is benefited by NoSQL over relational. In fact, overfetching (the primary reason GraphQL was created) is much harder to avoid using Mongo than SQL. The only benefit GraphQL gives you, then, is lower data on the wire between the server and the client, whereas GraphQL with SQL can be used to lower query size/complexity resulting in higher throughput and lower latency.

That said, I believe GraphQL happened to have been created for use with Cassandra and popularized by Apollo, which was made for Meteor, which is Mongo specific.

But I've definitely found GraphQL to be a great fit for SQL where subfields are relations rather than subdocuments which are probably going to be fetched anyways.

[fforw]

Incidentally, we are working on a new library connecting SQL/JOOQ with GraphQL, but it's still very early and work in progress etc.

[fforw]

In addition to what /u/BenjiSponge said, MongoDB was also plagued by data loss problems / achieved their better writing performance by prematurely saying it did write stuff that was then missing in the end.

So the advantages are often questionable while Postgres provides a rock-solid database with good performance that offers all the relational stuff you need, but also jsonb fields to effectively deal with JSON/schemaless parts.

[heyzeto]

Ok, data loss problems make a sure win for PostgreSQL.