Because of the domain registration costs, using emailing with Pawnmail is not free. This should dramatically reduce the incentive of using Pawnmail to spam.
Btw, @vortico I'm using Pawnmail for my new domain name and it looks quite nice so far, thanks!
- not a universal framework (you cannot create an app that has a static `/about` page but a dynamic `/search` page. With Next your app is either all static or all dynamic.)
If you need an ORM and you don't need any interactive views then Django is a good choice. (Interactive views are views that are stateful in the browser: an interactive graph, an interactive table, a To-Do list, etc.)
If your site is static then go for a static site generator such as https://github.com/nozzle/react-static. ("Static sites" are webapps/websites that are HTML-static: The HTML doesn't need to be dynamically generated at request-time but is static, no server is required, and your app can be statically served.).
Code-wise it is fully automated. But it's slow and it doesn't scale. We have to spin up new servers manually. As OP said, we'll need to make changes for ghuser.io to be scalable. Ideally GitHub adds an API that lists all your contribs. Which is (obviously) not in our hands but we are talking with GitHub.
> Could you make this work for gitlab, bitbucket and maybe even just regular old git repos as well?"
Yes totally.
Although we currently think that the best for the community is GitHub improving their GitHub profiles making ghuser.io obsolete.
Right now we'd rather do this with GitHub and not against GitHub.
But we don't know how much GitHub is willing to help us.
(We need changes to the GitHub APIs for ghuser.io to be scalable.)
> private repo
Yea we could do that as well. Give permission to our public key and we're good to go.
> why you would build this if you don't work at github?
Because Aurelien (OP) wanted/needed that so he just built it.
To the both of us it's basically a fun experiment.
That's why I've started a web framework with the goal of being entirely flexible. I've made all code ejectable, minimized/simplified the glue code (so that you eject beautiful code) and made the stack flexible (you can remove/add a frontend/backend/ORM/database to your app easily and at any time). That should give you the flexibility you are looking for.
I'm surprised nobody mentioned this but this website and the whole JAMstack thingy is basically a PR stunt from Netlify.
Static sites generators and the JAMstack are inherently crippled.
With a JAMstack, by design, everything needs to be rendered on the client. This means poor performance on mobile, loss of control over SEO, and virtually no SMO for dynamic content.
Kinda funny to promote a crippled stack that hard...
The mistake is not to learn about frameworks but to spend too much time with the details of one framework. Reading a 500 pages book about a specific framework is most likely a waste of time.
But getting an overview about the framework landscape is crucial.
Using the wrong tool can lead to a dramatically slower dev speed. Choosing React over Angular for an app with complex interactive views leads to an enormous increase in dev speed. (Angular is hell for complex views.)
Depending on what you need, setting up a React app is super complicated and time consuming. Especially when you need SSR.
There is a reason why frameworks such as Next.js, Reframe, and now this one are being used.
I'd actually say the opposite, it's tools like Webpack that don't have enough abstraction. I don't care how source maps are being generated, why on earth is it a good idea for Webpack to force me to dig into that? (If at least Webpack's default source map config would work out of the box but it doesn't.)
Parcel hits the right abstraction level much better.
If you need SPA then yea it's easy. But when you need SSR it becomes a whole different story.
Now imagine you want parts of your app to be SPA and some other parts of your app to be SSR. This becomes super complex. Frameworks like Reframe allow you to do that. (I'm Reframe's author (https://github.com/reframejs/reframe).)
Admittedly, mixing SPA and SSR views in one app is uncommon today but that's because people are not aware that they can do that. This will change.
We bring artificial intelligence to customer service and help companies increase their customer service efficiency. (We reduce the average handling time by up to 80%!) More at https://e-bot7.de/en/.
We are highly skilled engineers and we look for people that enjoy engineering and that focus on having an impact.
We are located in the heart of Munich, a city with a high quality of living close to the Alps.
There are many JS libraries that are wonderfully simple. I think the problem is:
- Too much choice; it's insane how much you have to decide before you get started: React or Vue? SSR or SPA? REST, GraphQL, or RPC? PostCSS or Sass? CSS-in-JS? What router? Redux or stateful components? Axios or Fetch API? Client-side rendering/routing or server-side rendering/routing? Webpack, Parcel, Create-react-app, Next.js, or Gastby? And the list goes on... I mean that's just nuts.
- State management is inherently complicated; people don't realize that 90% of the case you don't need interactive / stateful views to build a product. People implement bunch of useless interactive "niceness" that are overkill because React allows them to. If you use React as an HTML template engine then React is actually super simple and super neat.
How awesome would it be to have a framework that has sensible defaults for all these questions. And that educates how to decide certain crucial aspects.
For example:
- Use plain old HTML instead of interactive views if you can.
- Don't start with Redux. Instead, use Redux only after you know exactly why you need Redux.
Does someone know a tutorial for people like OP? Someone that knows programming but not modern web dev.
I want to write such tutorial.
> It's hard to build a mental model when things are happening at 4 level of abstractions away
I feel you.. the JS ecosystem needs more guidance. I'm trying to do that with Reframe: https://github.com/reframejs/reframe. The goal of Reframe is to precisely to guide you through web dev and give you a good and simple start.
It's new and work-in-progress though.
Feel free to hit me up on discord (https://discord.gg/kqXf65G) if you have questions about web dev. I'm happy to help.
Also, I'm looking for people to write such "modern frontend for backend developers" tutorial, if someone reading this would be up for it.
----
As for your questions:
> What is a minimal set of JS/CSS frameworks, templating engine, deployment tools, IDE I need?
If you are not sure whether you need an SPA or SSR, let me know. I'm happy to elaborate.
Another option is to use to the web framework I'm building (https://github.com/reframejs/reframe). The nice thing about it is that it allows you to build an SPA as well as an SSR app. And even better is that you can start with an SPA and easily switch to SSR later and vice versa. This means that you can start hacking today while later deciding whether SPA or SSR is right for you.
So my (biased) recommendation would be to use Reframe. Although Reframe is new and if you're not an early adopter, then it's probably nothing for you right now.
> a plethora of frameworks, transpiled languages, etc such as: Gulp, Typescript, JSX, Dart, Angular, React, Bootstrap, Babel, Wordpress, Drupal, Flutter, NPM, Web assembly, Vue.js, Minification of code before deploying, jQuery, and a gazillions others
I recommend to start with the simplest setup possible and later decide if you want to add niceness to your stack. That is: JavaScript with Parcel, Next.js, or Reframe. You'll eventually realize over time what you need or not.
And I wouldn't even start with bootstrap, instead I would use CSS flexbox.
As for API between your frontend and backend you can use https://github.com/reframejs/wildcard-api. It's another thing I built and it's much much easier than GraphQL and REST. Which is neat to get up and running quickly.
In a nutshell: start with minimalistic simple stack. You'll figure all the rest later while building your app.
> Auth support (custom and Google OAuth)
Just curious -- why do you need custom auth? Why not social login only?
This would be so neat but a problem is how do you distribute money in a fair way to creators? Spotify can give X dollars to a song author for each minute a user has listened to his song. You cannot easily do that with web content.
> Tech should be about results, it should not be a religion.
I couldn't agree more with this.
I'm trying to get a small library [1] I wrote popular and it's insane how much resistance I get because it doesn't fit the "mainstream religion" of using GraphQL.
People are brainwashed to think API = REST or GraphQL. How many times did I see a RESTful (or even worse GraphQL) for an internal API where RPC would be so so much simpler... (GraphQL is great for third parties but sh*t for internal stuff.)
"becoming the new SQL quickly" - Prisma, who led the way on that front, abandoned this pursuit.
"Learn GraphQL" - I'm not sure you need to learn GraphQL. You need to now that GraphQL is a powerful tool for APIs consumed by third party devs, such as the GitHub or Facebook API. But for internal APIs (and more than 98% of APIs are internal!), GraphQL (and even REST) is overkill and you'd be better off with RPC, such as Wildcard API [1] or gRPC [2]. Many developers will never have to build a GraphQL API in they entire career. Only few companies need to expose their data to third parties.
That said, for an API consumed by third-party developers, REST makes a lot of sense. Otherwise, which is like 98% of the APIs out there, RPC really is superior.
I've implemented a tool similar to what OP is building: Wildcard API [1]
> rather pointless HTTP semantics.
Agree. Actually, while implementing Wildcard API, I made sure to abstract away all HTTP semantics. With Wildcard, you don't think in terms of "HTTP verbs" but you think in terms of functions. Like you are naturally used to.
> It always baffled me how so-called RESTful APIs became popular
I believe REST became popular because it got lot's of exposure since all third-party APIs were using REST.
I've been thinking about language agnostic RPC as well. That would be so neat!
gRPC can already do that but gRPC's design is unnecessary bloated. The nice thing about RPC is its potential of zero-config setup. gRPC totally fails on that and it's painful to setup gRPC.
The RoR/python server could be used to automatically serve the RPC API. For a zero-config setup.
I can see the need for large projects to add structure between frontend and backend.
But until you hit that point you're better off with RPC. "Premature optimization is the root of all evil" holds here as well. A startup should start with RPC and solve structural problems as they arise. RPC has no lock-in; you can progressively replace RPC endpoints with a REST/GraphQL API.
The nice thing here is that, once you hit structural problems, it will become much clearer what the right solution is. Will it be REST or GraphQL? Or maybe something else entirely such as domain-driven separation of concerns? You will know better than today.
It is virtually impossible to know the needs of an architecture that doesn't exist yet.
Today REST and GraphQL are the default choice. But really, it is RPC that should be the default choice. And that's a widespread mistake in the dev community.
Wouldn't you agree? I'm curious to know what your thoughts are.
My goal is to rise awareness that RPC should be the default choice when creating an API.
> REST and GraphQL themselves are responses to RPC, and you neither take that into account nor address it
REST was introduced in 2000, jQuery in 2006, the iPhone in 2007, React in 2013. My point: API had different goals when REST was introduced. In 2000, we didn't have mobile frontends nor dynamic browser frontends. There was little need for frontend-backend communication.
For an API that was meant to be consumed by third-party developers in 2000, REST was an excellent choice.
But, today, to communicate between a backend and a modern frontend, RPC is most of the time the better choice.
> you simply open Pandora's Box with "but there's a third option, and it's full of more options".
I disagree with that.
It's pretty clear:
- For an API between a Node.js backend and a browser frontend, Wildcard API offers a super simple RPC solution.
- For an API between a python/go/java/... backend and a browser/mobile frontend, create custom JSON server endpoints.
- For communicating between backend services, use gRPC.
I don't see many use cases where you'd need something beyond what I just mentioned. Maybe I'm missing on some important use cases?
I'd recommend against using JSON-RPC. (Using JSON-RPC requires you to implement too much non-standard stuff that will only exist within your company). I'd recommend gRPC instead.
The problem with RPC is that people are not familiar with it. It may seem "complicated" at first because people are not proficient with it. But, and that's what I'm trying to show with my Wildcard API project, RPC is actually super simple. Fundamentally, RPC is simply about defining a function in one env and calling it remotely from a different env, that's super simple.
That said, RPC is no good if your API is meant to be consumed by third-party developers. In that case you need to create a generic API with REST or GraphQL. (Although my prediction is that RPC will eventually also become a viable option for third-party devS in the future... basically by introducing a schema to RPC... but that's a whole different topic.)
The most fundamental difference between RPC and REST/GraphQL is that RPC is schemaless whereas a RESTful or GraphQL API has a schema.
The whole point of a schema is to have a generic API. Whereas with RPC and any other schemaless approach such as SOAP, you are essentially building a custom API that is only usable for your clients.
That's precisely the reason why RPC is not usable to create an API that is meant to be used by third party devS.
Third party devS need a generic API. That's the point.
Also, a generic API decouples whereas a custom API tightly couples.
WSDL is actually only describing the API - it's not defining a schema. So SOAP is not and was never usable for a third-parties. Same for gRPC's proto files.
I do appreciate your encouragement but I don't see where I concretely am missing out on something important. You simply state that I'm lacking knowledge without ever concretely showing the flaws of Wildcard.
> You are almost close to the enlightenment
That's just not very helpful. You are telling me that I'm missing an important point without telling what it is I'm missing.
I'd love to be shown wrong. You would for sure save me a lot of effort if you'd pin point my lack of knowledge.
For a Node.js backend and a browser frontend, what exactly is the problem with Wildcard API? (https://github.com/reframejs/wildcard-api). As long as you don't have third-parties consuming your API, I'd say that Wildcard is superior to GraphQL and REST >95% of the time. Especially when using Wildcard with TypeScript.
> There's always been a pendulum swinging between tightly coupled RPC standards and loosely coupled data interchange standards (or one made from the other in all sorts of combinations). It's a fact of software development life since essentially the dawn of the industry.
Interesting. I've not been a programmer long enough to know all that :-).
For those who don't know what RPC is, RPC (Remote Procedure Call) denotes the practice of calling a procedure that is defined on a remote computer (or different process) as if it were defined locally on the same computer (or different process).
Wildcard fully abstracts away serialization and the transport protocol: you simply define a function and call it remotely.
Wildcard only supports JavaScript (Browser & Node.js) for now but it could in principle support all kinds of languages.
This is exactly what I was looking for! I wonder though: how can I trust you guys that you'll successfully manage to redirect all emails? Loosing emails is really bad.
Also I'm curious; how did you manage to land #1 on Google for the query "free email redirection service"?
Ok sounds good :-). I just registered with https://forwardemail.net/ instead though. Because they are older which makes me trust them more - that they won't close shop next week. Although the UX of improvmx seems much better. Thanks for the reply.
Instead of Hasura and GraphQL, you can use RPC and directly write SQL queries to retrieve and mutate data.
One way to think about this is that with RPC you remove the whole API layer and directly write SQL queries instead, while permissions are defined programmatically on a case-by-case basis. This is much simpler than Hasura!
Curious to know what you think of the React + RPC (e.g. https://github.com/reframejs/wildcard-api) + PostgreSQL stack in comparison to React + Relay + GraphQL + PostgreSQL?
RPC tightly couples frontend and backend. Decoupling is usually only needed for (very) large applications; while getting there you migrate from RPC to GraphQL.
Do you really need to decouple frontend and backend in the first place?
Why not separating concerns instead of separating technologies? Tight coupling of UI with database but decoupling of e.g. admin UI/backend from end-user UI/backend.
I'm the author of a Node.js RPC implementation (https://github.com/reframejs/wildcard-api) and the idea is the exact opposite of what you are prescribing: highly coupled frontend business logic with database schema/queries. Makes things so much simpler, in my experience.
I agree, Hasura and Wildcard have different goals. Still, the merits of each tool can be talked and discussed about.
> you aren't writing any SQL queries. You are creating your database schema and then launching the respective apps. Obviously some customization will be necessary since almost no app are 100% CRUD.
I'm not against ORMs. On the contrary, I've always been (and still am) looking for an ORM that takes care of 90% of queries (basic CRUD queries) while preserving the full power of SQL for the 10% of queries that require more powerful queries. Most ORMs do that part wrong and make writing custom SQL queries complex. I really want such ORM and I even tinkered and implemented one for a hobby project.
Also I believe that an ORM to be a wonderful combo with Wildcard, such as Prisma. (Prisma is pretty much an ORM and can be used without GraphQL.) I would argue that Prisma + Wildcard to be superior to Prisma + GraphQL. (With the exception of when you need need third-party devS to access your data -- you then need a generic API with either REST or GraphQL.)
> But I took a look at your RPC tool, and it adds a lot of boilerplate work.
I couldn't disagree more; Wildcard is deliberately designed to abstract away as much boilerplate as possible. I'd be more than happy to see a concrete example that proves me wrong. My guess is that you won't prove such example because there virtually isn't such.
> This RPC boilerplate is exactly why alternatives like Hasura, Prisma, and Postgraphile exist.
That's a vague sentence and doesn't make any sense to me.
> it is just as simple, just as much a layer on top of the database.
Wildcard is only a couple of KLOCs while Hasura & co large and complex tools developed by teams and backend by big VC money.
You can read Wildcard's whole documentation in 10 minutes. Reading Hasura's entire documentation is much larger than Wildcard's.
It speaks volumes about how much simpler Wildcard is in comparison to Hasura.
It's weird to say that Hasura is as simple as Wildcard.
> the client doesn't have to know if it's talking to a relational database, a Redis cache, a REST data server, an in-memory data model, or whatever.
Such decoupling is mostly useful for very large projects. The vast majority of apps out there don't need such decoupling. Separation of concern is important, but based on concern not on technology.
> Your tool on the other hand is just another vendor-specific ORM or manual query engine.
It's weird to call an RPC implementation an "ORM" or "query engine". I'm not sure how an Software Engineer is able to mix up "RPC" with "ORM".
Honestly, your whole post is weird to me, I'm not sure what your motive is. You seem to try to put down an open source project that is being developed by someone in his free time and without any remuneration. That's disgusting and without taste. If you only have a lack of tact then I apologize for my words.
Just to be clear I do like many aspects of Hasura. The problem is that, 95% of the time, GraphQL is not being used in the right situations. GraphQL when used correctly is a lovely tool. (Basically GraphQL = generic API for third parties. If you don't need third parties to access your data then you don't need GraphQL.)
I'm a minimalist and as such I have a problem with complex solutions to simple problems. That's my whole point.
My dream ORM is a an ORM that is designed with a) an obsession on simplicty, b) simple ORM CRUD queries that cover 95% of the data mutation/retrival needs, c) allows you to write "native" (no)SQL queries directly for the 5% cases when you need more complex queries, and d) automatically takes care of migration for 90% of the cases.
The ORM should be trivial to understand, the documentation super small, and the ORM should get entirely out of your way if you want to use your database directly without the ORM. Most ORMs out there (if not all) get these things wrong.
Hasura, Prisma & other auto-generated GraphQL tools are essentially ORMs. Unfortunately, they also get the above listed things wrong. I like that they auto-generate a GraphQL schema, that's neat. That's not my problem. My problem is that they are tightly coupled with GraphQL. That's nonsense. Because (and Wildcard is a living proof of this) you don't need GraphQL for the vast majority of apps out there. People need to understand that GaphQL = generic API = third-party devS. You don't need to expose your data to third parties? You don't need GraphQL. Period. (I hear people arguing about decoupling frontend and backend by using a generic API but that's an old and out-dated idiom, which is another topic I'd be happy to elaborate if you want.)
A simple ORM with a plugin that auto-generates a GraphQL schema? Hell yeah that's awesome. You'd then use the GraphQL plugin only when you need to expose your data to third parties. That's cool.
You don't need to expose your data to third parties? Use an ORM with RPC.
RPC is fundamentally simpler than GraphQL. Why on earth should I use something inherently more complex if I can use something so much simpler?
For example, have a look at how permissions work with Hasura and compare this to Wildcard. The difference is worlds appart in simplicty.
With Wildcard, permissions are written in code:
// Node.js server
endpoints.deletePost = async function(){
// Only admins are allowed to remove a post
if( !user.isAdmin ) return;
// ...
};
This means that you don't have to understand anything to do permissions -- simply write if statements, just like you are used to while programming other sutff.
With Hasura, you have to use Hasura's custom system of role-based permissions. What I find most annoying about these is that they are not defined in code. With Wildcard all permissions are written in the code - I can simply read them while reading queries.
I hear your arguments saying that Wildcard is new and I understand that you don't want to adopt something that is the "bleeding-edge". (From my perspective; from your perspective, experimental ;-).)
I agree that my way of promoting Wildcard on the whole Hasura thread was less than ideal, I'll improve.
Developed: several single-page Web App
Portfolio: http://www.brillout.com/dev
Skills:
Hourly Rate: 30$Contact: dev@brillout.com || +1 646 504 9833 || +49 15771 95 95 02