Can you talk about or point me to docs on the different philosophies between this and nextjs? In particular next already makes bundle optimization, splitting, lazy-fetching and serverless deploys pretty automatic. Why not start with next and work on incorporating the DB/business logic functionality? Related: why Prisma?
What next is missing is a blessed omakase way to deploy it with a DB.
So its missing a complete "rails" solution? that's a big "missing"
I mean, why are you even comparing them?
A few questions:
- Do you intend to have strong typing (Typescript) all the way through? Most of the examples seem to be in plain JS. Not that that's a bad place to start, but I have a dream of typing a schema for a new model once and having it immediately typecheck all the way to the frontend code.
- Will there be an ability to automatically generate admin interfaces, form and all, from database schema? Django's ModelAdmin is annoying to customize, but it's unparalleled in getting a GUI together in minutes for a trusted operational team. And React-Hook-Form's support for dynamically generated fields could be really powerful in this regard.
- Both Rails and Django have patterns of "as long as this file is in the right place and/or has the right inheritance hierarchy, I won't need to write boilerplate." Is this a goal of this project as well? For instance, for the service file in https://redwoodjs.com/tutorial/side-quest-how-redwood-works-... seems to be something that would be nearly identical, save for the name of the model, across a number of things. Rather than scaffolding, could there be a way to inherit from a generic superclass (or the functional equivalent), fully overrideable, similar to how https://docs.djangoproject.com/en/3.0/topics/class-based-vie... allows any view to inherit from a ListView or DetailView?
- Typescript is definitely a priority for us. But implementation so far is starting with the backend (see https://github.com/redwoodjs/redwood for current), which isn't inclusive as of yet. We are looking for community involvement here as well.
- Admin interface: ah, very interesting. Could definitely be on the roadmap in the future. We're off to a great start with the Scaffold generator, which uses the schema to create all the pages necessary to run end-to-end CRUD operations on a database table. See https://redwoodjs.com/tutorial/getting-dynamic
- Boilerplate: The short answer is "yes indeed"! It's not 1-to-1 with your example, but there are lots of cases where you'll find this thinking+implementation. Again, the tutorial walkthrough is the best place to see some of this in action.
Modern web development desperately needs a framework that integrates well with technologies like SSG, Graphql and Nodejs in general, that ships with sane configuration defaults for all the involved layers.
This is important, since SSG/SPA hybrids solve a lot of frontend issues by default and Graphql is a very expressive protocol which helps to avoid tightly coupled data transformation logic on the frontend.
I'm currently very interested in Nodejs specifically since JS is a transpilation target for a lot of languages and WASM.
I'll keep my fingers crossed, that you find a solution for integrating the persistence layer nicely as well. A simple and reliable DB like SQLite could be a very good default, since now you are essentially just dealing with files.
I think database and ORM integration in a framework like yours is very tricky in general. It has to be flexible enough to serve different needs but also well integrated and easily deployable. Good luck with that!
Looking forward to try this stuff out and possibly provide further feedback.
It's on the way!
It has evolved very rapidly as the web grew and these frameworks are a natural outcome of everyone trying to create some order from the chaos and figure out a proper architecture and way to do things.
The good news is you have lots of choices and it runs everywhere. Bad news is the sprawling mess you have to go through to find the good stuff.
But here I am... There was a lot of time spent trying to figure out how to use these technologies, and we're glueing those technologies together with our personal taste.
Edit: The twitter thread from the author is a great summary of Redwood and its benefits https://twitter.com/mojombo/status/1237441122097487873
one vm => many lambdas/microservices
react => server side rendering and state hydration, throw redux in there too
prisma => you can't beat the DB with code. Learn SQL and remove the middleman.
Jest => fair enough I guess, but I wouldn't use rspec when Ruby had minitest out of the box
Caching/Static site => wut? ... wut? there's much more to caching than HTML.
routes.js => probably great on the server, not so much on the browser.
And the best for last...
graphql => not a replacement for REST. You can do more with less by just making your client do the work or going with backend-for-frontends. If you don't understand your network then graphql is an easy vector for DOS (speaking from experience).
Meanwhile I can spin up Laravel, Rails, Spring or Django up and get a solid application running in a fraction of the time while in JS land, client server arch is a seemingly unsolved problem.
I sound bitter but I'm more incredulous. I don't actually enjoy writing for the browser any more, there are too many divergent trends.
This might be a slightly controversial opinion, but I don't think the time it takes to get an application running with a framework is a relevant metric. Being able to get an application up and running fast is only a useful benefit when you're first starting out and trying things. If you're choosing a tech stack and you're going to be working on something for months or years, the fact that you can see something on a screen after an hour or after 3 days is completely insignificant compared to how good it is to work with in the long term.
Choosing a technology because you can start working on a new application quickly is the wrong way of thinking about your tech stack.
When GraphQL came out I was quite honestly shocked that this didn’t get more attention. It’s essentially trivial to not notice that a query could cause the server to loop heavily. User > Friends > Friends = easily 10000 results, and that’s the simplest top-of-the-head example I can think of. When an object has even 3 or 4 possible relationships, there are exponentially more attack vectors.
And on a minor note: the fact that objects are returned inline makes a query for duplicates that much larger in KB.
If you go to https://redwoodjs.com/ right now and disable Javascript on the page, you will get the same amazing fast experience at literally 5-10x less size. The only difference? The sidebar in the tutorial will not display properly.
JS enabled: 403KB transferred, 1.0MB resources. Of them: 276 KB JS, 82 KB images, 27 KB custom fonts, 10 KB HTML, 5.5 KB CSS
JS disabled: 99 KB transferred, 142 KB resources. Of them: (0 JS, 0 custom fonts), 82 KB images, 10 KB HTML, 5.5 KB CSS
I find that JAMstack is great until the need for recurring or out-of-band processes comes up. In Rails of course there are jobs that can be backed by Sidekiq or what have you, and additionally on a VM one can always set up a cron job to invoke some Rails tasks.
For JAMstack there is no clear alternative, as far as I can see. Manually setting up a recurring lambda function (granted, I have not yet done it) seems to be annoying enough that I would rather just deal with a VM instead.
https://autocode.stdlib.com/new/?event=scheduler.daily&event...
This link will set up an automatically scheduled script / endpoint you can deploy in a click. Disclaimer; I built a lot of it. (Founder.) Warning is that there's a signup wall right now but it is free to use. Based on feedback we might be removing the signup wall at some point just so more people can check it out.
I'm previously the author of Nodal [1], a Node.js API framework that had quite a bit of early popularity -- we transitioned to building Standard Library [2] to focus on easily building APIs and combining them for simple backend workflows / integrations. Fits with JAMStack pretty well, generally, and our users aren't just developers; it's accessible to business users as well, provided they don't mind learning a little code. :)
I guess Redwood's model is a little more than JAM stack, since "Rails" for JS would imply it does a lot more than the JAM part, and that's what it looks like on the site.
Then we could undoubtedly abstract this into something and deal with it at deploy time.
Then I saw Tom Preston-Werner's involvement and my interest level raised considerably. I'm still not sure if there's a market for this per se, but the bone-fides of the dev team is certainly a good sign.
Redwood started as an experiment, and we'll see where it goes, but my intuition is that it will fill a need that many React developers currently have (namely: the lack of integrated solutions to all the technologies available in the ecosystem). It's certainly something that I want!
I honestly will never understand why people say things like this. As though there's no room for progress. As though there aren't alternatives that may or may not be better. Imagine if the folks building React thought "ya know, we got Angular, so why are we doing this?"... Or any of the many, many other similar scenarios. It's how we make progress.
I would have agreed with you already until I read the above sentence. Having a famous programmer isn't really a great reason or argument to adopt yet another N + 1 web frameworks. Sure, some have reasons to exist but appealing to authority is hardly any valid reason here.
Even that aside, if everyone were to adopt this by the time it reaches v1.0, someone will complain via writing a Medium blog-post and introduce another web framework on top of Redwood or introduce some other improvement for Redwood but as a fork of the project rather than a contribution back to Redwood.
Here we go again.
It's about competence.
Would you not have increased confidence in an NBA team after hearing Stephen Curry had joined it after the previous season? I think you'd be highly irrational not to.
I've heard GraphQL proponents call joins "premature optimization", and I don't even know how to respond to that…
Obviously my understanding is that at Facebook-scale you're not really able to have the luxury of joins, and have to accomplish your query logic in other ways...but that strikes me as joins being something you have to relinquish if necessary, rather than being a premature optimization.
These are the same people that build something complaining about 'overengineering' and when they get stuck just end up shutting down and rewriting stuff.
Some "dynamic" server side content was also easily included in a cronjob. That way I fetched the Twitter feed of a few accounts and rendered this into the static HTML.
I did it, because it was really fast to build, could scale, development and deployment was easy for the HTML, etc.
What I didn't had at the time was FaaS and I think the architecture could benefit from this. I had Docker containers running the API and the reverse proxy needed to do some routing, so I still had a server running, but I didn't need a database. I had to teach the marketing department how to write Markdown in GitLab editors, though.
so, I guess that's good. I was afraid the M was going to be Meteor.
It should be closer to the mongo api.
await prisma.users.findOne({ where: { id: 1 } })
await prisma.users.findOne({ id: 1 })
It is trying to do too much. There is a hard limit of where ORMs try to take over too many of the things you do in SQL and become slow and complex and a big black hole. prisma tries to do migrations, table creation, etc, etc. These things rarely work properly.
Lazy loading never works. Somewhere litered in your code you access a field that is outside the scope of the pulled in data and it is in a loop and suddenly you have 100 requests. You have to look through your entire function to understand which fields are inside and outside of the scope of the query, and add more includes or whatever.
There are security issues with ORMs that traverse and save relationships, as github itself found out. You add user__roles form field maliciously on the client side to a form that was just supposed to update the user and not the roles, then suddenly you find your user.save() method on the server-side has traversed and added new roles to a user.
I am writing a kind of orm today based on the mongo api without all the $ signs, much like prisma, but closer and without all the additional things. github username is thebinarysearchtree.
ORMS should just be for fairly simple, single table tasks. That way they get out of the road and don't become some big complex thing that ruins performance and adds its own complexity.
> It seems to take a lot of inspiration from the mongo api
That's an interesting comment but I'm not sure it's quite accurate. I think where we're taking quite a bit of inspiration from MongoDB is the idea of "thinking in objects" because this is much closer to the mental model developers have when they work with data. We are currently already working on an improved API of Prisma Client [1] that looks less like MongoDB but should feel a lot more ergonomic.
Regarding your example of removing the `where` from a `findOne` call. In this case it's needed because you can also select/include [2] fields and/or relations:
await prisma.users.findOne({
where: { id: 1 },
include: { posts: true }
})
await prisma.users.findOne(1).load({ include: { posts: true } })
I just want to stress that Prisma is not an ORM! ORMs are characterized by the fact that classes are mapped to tables and you have complex model instances that carry logic for storage, retrieval, serialization, deserialization and often custom business logic. Prisma does none of that! It provides an auto-generated and fully type-safe database client that's tailored to your database schema. Any data you'll ever retrieve is fully typed and comes in the form of plain old JS objects that a are easy to reason about.
> prisma tries to do migrations, table creation, etc, etc. These things rarely work properly.
I'd love to learn more about where you think Prisma's migrations approach falls short! IMHO moving towards a dclarative migration system based on an intuitive data modelling language is much closer to how developers are thinking about their data than using SQL migrations. One of our users once described it like this:
"What Prisma does for migrations is essentially what React does for rendering. A user need only describe the current state, but not the operations to get to that state. So, thank you for doing this to databases as React (and others) has for UIs!"
> Lazy loading never works. Somewhere litered in your code you access a field that is outside the scope of the pulled in data and it is in a loop and suddenly you have 100 requests.
Do you mind elaborating how/where you see this problem happening in Prisma?
> There are security issues with ORMs that traverse and save relationships, as github itself found out.
Again, Prisma is not an ORM and I have a hard time seeing how this applies to it.
> ORMS should just be for fairly simple, single table tasks. That way they get out of the road and don't become some big complex thing that ruins performance and adds its own complexity.
I fully agree with this poinit and it's one of the core desiign goals of Prisma. If you feel Prisma doesn't achieve this, we're doing something wrong...
All that being said, I really appreciate your thoughts and feedback and would love to see you in the Prisma Slack [3] and sharing your thoughts in our GitHub issues.
[1] https://github.com/prisma/specs/issues/356
[2] https://github.com/prisma/prisma2/blob/master/docs/prisma-cl...
That said... am I the only one that thinks that anything that is JS based seems ridiculously complicated to use? I don’t do much UI work, but any time I look at using react or similar it feels like there are a lot of moving parts and a lot of steps to perform before you can even get started on something useful.
I think the reality is web applications stand on the shoulders of lots of giants. We're only able to get anything done thanks to abstraction that someone else did for us. We still have a need to see below the surface occasionally, though, and finding the balance between readability and customizability is an eternal struggle. Plus, everyone has their preferences: I hated Angular at first because of its steep learning curve, and now love it for its strictness.
I hate docker in development!
Not suggesting? Or suggesting not to?
Also: I'm not sure what you are trying to say here, what FWs are you referring to?
I'm working on something similar. I hope to pick up some ideas ;)
My project is about helping create more traditional JavaScript applications, not necessarily JAMstack. It is inspired by the Self programming environment created at Sun Microsystems in '95, so it's not a framework per-se, but a combination of a framework, an editor (VS Code plugin) and (in the future) infrastructure.
The project is called Huncwot: https://github.com/huncwotjs/huncwot
* it supports TypeScript out of the box * it provides background processing (via Postgraphile Worker) * it aims to support only PostgreSQL, so that we could conveniently use all those beautiful PostgreSQL features that are usually «hidden» by ORMs * I'd also like to make SQL more popular ;) * there is a bit of inspiration from Clojure * it favors the function composition, e.g. for handlers * it comes with a built-in authentication/authorization, which you shouldn't probably use in production just yet * it is still very alpha * for the front-end you can use React, but also Vue.js and possibly Angular or Svelte * and many other things which I haven't yet described in the README as I work on this on the side, mostly alone
There is also fantastic Dark Lang (https://darklang.com/) in the same, quite similar yet different.
And congrats to mojombo and team! You probably already use something Tom wrote without realizing it.
I like rails, but in js world may be not so good idea to reimplement or integrate everything related to ui, routing etc. Meteor.js was not very successful with this model. I think routing or UI on react-native/web/blessed/VR is too different to be part of one framework.
But I see the usefulness of framework with functionality related to data fetching and business logic.
I consider perfect stack for this things is Postgress->Hasura (or also Prisma)->mst-gql->mobx-state-tree. You create database schema and everything up to models on client is autogenerated and each part of this stack could be updated, customized or completely rewritten. This stack could be used on react-native or web or any other js platform.
Will be watching it with great interest. Good luck!
We'll definitely support Typescript, we're almost there and will make the experience feel amazing.
The boundary between the API and WEB sides is GraphQL and we're looking at making the schema typing available on the WEB side.
We're using yarn workspaces!
We already have all those pieces in place, along with the ability of swapping any one piece with a different one; say, if we wanted to go RESTful we only need to swap one block.
It does look gorgeous tho; how would one go about gradually adopting it?
It's very true that all the prepwork is pretty costly, hence my eagerness to try and adopt random bits and pieces even at this stage; it might end up saving us time down the line haha
While I have you around... what would be a good toy to build with this? Our megalithic, business rules heavy app sounds like a potential good fit for the Redwood, but it's entirely too large a bite to tease our engineering leads with.
>And every time some information will be lost
Maybe from an embedded systems/OS point-of-view, but these statements are just not true on the web.
Just like Next.js was built for zeit/now, redwood was built for Netlify.
Since Top Prester-Werner (Author) is in the board of Netlify this makes sense. But is it a good idea for frameworks to be tied to specific deployment platforms? Unsure, we’ll see!
For me: I need services that support the UI, as well as a public-facing API with basically the same data. I don't have the time/resources to build/maintain them separately, and my perception is that GraphQL and the wider ecosystem around it haven't yet reached the same level of ubiquity/maturity as plain-old REST.
A single, well-designed REST API that can be consumed by my own UI as well as public clients is how I'd prefer to handle it right now.
as a React dev as well, I particularly like the integration of GraphQL into the Cell format. This will work especially well with render-as-you-fetch React Suspense. I think if you throw in scoped css you'll have the ultimate vision of the React Single File Component format.[1]
1: https://www.swyx.io/writing/react-distros/#what-other-react-...
I personally love styled-components and I had tighter integration with it in the start, but we decided to not be opinionated about CSS frameworks... That may change ;)
I took a look at the example:
https://github.com/redwoodjs/example-blog
As I understand "JAM Stack" the point of the M is to have large chunks of your application pre-rendered.
However in this example; the blog pages are client-side rendered based on a graphql query that goes into postgres database.
Am I missing the point of this? It looks like a standard rich-client with API backend architecture.
One question, is the React app being pre-rendered at all before being stored on the CDN? If not, how does it qualifies as a JAMstack project? If the React app is being completely rendered on client side, then I don't see any difference with a regular Next.js (without generating a static site) project but I certainly see lots of differences with Gatsby for example.
Thankfully, we're building on the backs of giants here.
We're glueing a bunch of the technology together in a way that makes it feel idiomatic, documenting it and asserting our opinions on how to use it.
redwood is full-stack, has an opinion on graphql/prisma as part of your data layer, integrated into Cells for declarative loading states. its still super early days but you can feasibly view it as doing the same thing Rails does in terms of organizing and picking techs for you for all parts of a stack, including setting up scaffolding for you.
- frontend and backend in the same code https://nextjs.org/docs/api-routes/introduction
- graphql based - https://github.com/zeit/next.js/tree/canary/examples/api-rou...
- hybrid static page support - https://nextjs.org/blog/next-9-3#next-gen-static-site-genera...
- jest - https://github.com/zeit/next.js/tree/canary/examples/with-je...
- CMS providers - https://nextjs.org/blog/next-9-3#collaboration-with-cms-prov...
- pretty url routing - https://github.com/zeit/next.js/tree/canary/examples/with-pr...
Building any "Rails for JS" idea is a huge undertaking, purely from the sheer scope of the Javascript (inc. NodeJS) ecosystem.
I recently stepped through this tutorial, which does somthing similar, and uses FaunaDB - turned out pretty nicely.
https://egghead.io/playlists/building-a-serverless-jamstack-...
Code for the DB part is here - I know it doesn't use Prisma, would be great to see Redwood support this: https://pastebin.com/aJvFSjsa
I only had time for a brief look through it but searching for "redux" and "state" didn't bring up anything; do you have an opinionated approach to global state management?
Keen to check this out when I have more time this week!
No thanks, we have Blazor now.