3 ms·

"Pushup uses file-based routing, so adding a page adds a route to your app." Make sure to have a clean way of escaping that and having some richer concept of h

by jerf 4y ago

"Pushup uses file-based routing, so adding a page adds a route to your app." Make sure to have a clean way of escaping that and having some richer concept of how to route. This was the original way routing worked, back in the ASP (not ASP.net, the predecessor), CGI, original PHP days. We moved away from it for good reasons. It works well early but has scaling problems over time. I'm not saying don't have it as a default per se... just make sure you have a "if you need to do something else here's how to override it". I also strongly advise against trying to guess what the overrides might be and building special cases for "the three things I think people may need to do beyond thsi". I've got a router in my system that looks at client-side TLS certificates if it comes from certain IPs and uses LDAP authentication if it comes from certain other IPs, and does different things if the auth fails for each case. You'll never be able to guess all the possible ways people want to route. You need to make sure you don't lock the users into this so hard they can't escape except by leaving your framework entirely. Edit: Also, I didn't look into this deeply, but if you throw away the ability to have middleware on specific routes you've really caused a big problem. The Go ecosystem is fairly dependent on that.

robertlagrant 4y ago
I have the same instinct (JSP / JSF had the same concept) but I must say, making pages as files in next.js is really nice. You can have all your dynamism within them, but having a simple way to do overall routing is lovely.
- jerf 4y ago
  It is nice. It is easy. There's a reason we started there. Then, suddenly after a certain amount of scaling, it isn't. And it's not like that's an impossible situation either, but you end up with all the consequences of building a framework to do X and then having to build an inner platform[1] to do some other Y inside of X instead. [1]: A technical term: https://en.wikipedia.org/wiki/Inner-platform_effect https://en.wikipedia.org/wiki/Inner-platform_effect
  - robertlagrant 4y ago
    Sure. It's a tradeoff either way - ergonomics for common cases or not. I imagine in your case you're constructing lots of custom logic anyway, whether it's in an API gateway (or similar) component to put the auth logic before the application, or put the logic in some before_request handler in the web application.
    - leerob 4y ago
      Curious if you're explored the new `app` directory (beta), which includes a new routing system in Next.js? Open to feedback: https://beta.nextjs.org/docs/routing/fundamentals https://beta.nextjs.org/docs/routing/fundamentals
      - robertlagrant 4y ago
        I haven't, but I've just had a read. It looks well thought through and opinionated, which is what I'd expect and want from NextJS. Time will tell if it misses a load of cases, but I can't think of any. I'm not doing any UI work at the moment, and while I wanted to introduce NextJS to my new team's new project, we tried it but couldn't get it to work with our slightly tricky component tech (StencilJS). I think that's a StencilJS <-> ReactJS issue rather than a StencilJS <-> NextJS issue, though.
- mijamo 4y ago
  Next.js routing limits have been for me the number one reason not to use it unfortunately.
  - leerob 4y ago
    Can you share more? With Middleware, you can run any arbitrary code to control routing: https://twitter.com/nextjs/status/1610663442825854980 https://twitter.com/nextjs/status/1610663442825854980. And with the `app` directory (beta), we're reimagining the Next.js routing system from the ground up: https://beta.nextjs.org/docs/routing/fundamentals https://beta.nextjs.org/docs/routing/fundamentals.
    - techpression 4y ago
      Not the author but for me it’s insane that the router doesn’t do http routing on verbs but rather leave it to be repeatedly reimplemented in every single page (and the fact that you can’t do simple things like what’s been available in rails for over a decade with resources).
      - robertlagrant 4y ago
        Can you give an example of routing based on verbs?
        techpression 4y ago
        https://hexdocs.pm/phoenix/routing.html https://hexdocs.pm/phoenix/routing.html
        robertlagrant 4y ago
        Understood. This I think is a slightly different way of making a web application - NextJS is built on REST calls and client-side view changes. If I've understood correctly, your Phoenix example is more like traditional full page request response programming, where you can post a form and get back a whole new web page. Phoenix no doubt has magic to make the whole page not reload, but point being that I think a lot of NextJS's target users are developers who come from a REST + SPA background, and wouldn't think to send some data and get a changed view back. They'd send some data, maybe get a response, update their client side data store and their view would change automatically.
- moltar 4y ago
  I honestly don’t get all the file routing hype. How hard is it to setup a React Router? It’s like a few lines of code and you get a massively flexible setup, without any lock-in.
TylerE 4y ago
At the day gig (old school in house python framework) we used file based routing. Works great. The few times we need to get fancy mod_rewrite is pretty easy. The lack of ceremony is refreshing.
paulsmith 4y ago
> If you throw away the ability to have middleware on specific routes you've really caused a big problem. The Go ecosystem is fairly dependent on that. Agreed! Pushup pages compile down to structs that implement http.ServeHTTP. And an entire Pushup app is just a http.ServeMux too. So it should be trivial to insert middleware (although there isn't Pushup syntax for that yet), and/or embed a Pushup app in a larger Go app (this is quite possible today).
geenat 4y ago
>It works well early but has scaling problems over time. How? Otherwise calling this out as cargo cult. As I remember the main reason we moved to app routing is because of the single process nature of non-blocking async code which was popularized with node / express.

by jerf 4y ago

robertlagrant 4y ago

I have the same instinct (JSP / JSF had the same concept) but I must say, making pages as files in next.js is really nice. You can have all your dynamism within them, but having a simple way to do overall routing is lovely.

jerf 4y ago
It is nice. It is easy. There's a reason we started there. Then, suddenly after a certain amount of scaling, it isn't. And it's not like that's an impossible situation either, but you end up with all the consequences of building a framework to do X and then having to build an inner platform[1] to do some other Y inside of X instead. [1]: A technical term: https://en.wikipedia.org/wiki/Inner-platform_effect https://en.wikipedia.org/wiki/Inner-platform_effect
- robertlagrant 4y ago
  Sure. It's a tradeoff either way - ergonomics for common cases or not. I imagine in your case you're constructing lots of custom logic anyway, whether it's in an API gateway (or similar) component to put the auth logic before the application, or put the logic in some before_request handler in the web application.
  - leerob 4y ago
    Curious if you're explored the new `app` directory (beta), which includes a new routing system in Next.js? Open to feedback: https://beta.nextjs.org/docs/routing/fundamentals https://beta.nextjs.org/docs/routing/fundamentals
    - robertlagrant 4y ago
      I haven't, but I've just had a read. It looks well thought through and opinionated, which is what I'd expect and want from NextJS. Time will tell if it misses a load of cases, but I can't think of any. I'm not doing any UI work at the moment, and while I wanted to introduce NextJS to my new team's new project, we tried it but couldn't get it to work with our slightly tricky component tech (StencilJS). I think that's a StencilJS <-> ReactJS issue rather than a StencilJS <-> NextJS issue, though.
mijamo 4y ago
Next.js routing limits have been for me the number one reason not to use it unfortunately.
- leerob 4y ago
  Can you share more? With Middleware, you can run any arbitrary code to control routing: https://twitter.com/nextjs/status/1610663442825854980 https://twitter.com/nextjs/status/1610663442825854980. And with the `app` directory (beta), we're reimagining the Next.js routing system from the ground up: https://beta.nextjs.org/docs/routing/fundamentals https://beta.nextjs.org/docs/routing/fundamentals.
  - techpression 4y ago
    Not the author but for me it’s insane that the router doesn’t do http routing on verbs but rather leave it to be repeatedly reimplemented in every single page (and the fact that you can’t do simple things like what’s been available in rails for over a decade with resources).
    - robertlagrant 4y ago
      Can you give an example of routing based on verbs?
      - techpression 4y ago
        https://hexdocs.pm/phoenix/routing.html https://hexdocs.pm/phoenix/routing.html
        robertlagrant 4y ago
        Understood. This I think is a slightly different way of making a web application - NextJS is built on REST calls and client-side view changes. If I've understood correctly, your Phoenix example is more like traditional full page request response programming, where you can post a form and get back a whole new web page. Phoenix no doubt has magic to make the whole page not reload, but point being that I think a lot of NextJS's target users are developers who come from a REST + SPA background, and wouldn't think to send some data and get a changed view back. They'd send some data, maybe get a response, update their client side data store and their view would change automatically.
moltar 4y ago
I honestly don’t get all the file routing hype. How hard is it to setup a React Router? It’s like a few lines of code and you get a massively flexible setup, without any lock-in.

TylerE 4y ago

At the day gig (old school in house python framework) we used file based routing. Works great. The few times we need to get fancy mod_rewrite is pretty easy. The lack of ceremony is refreshing.

paulsmith 4y ago

> If you throw away the ability to have middleware on specific routes you've really caused a big problem. The Go ecosystem is fairly dependent on that. Agreed! Pushup pages compile down to structs that implement http.ServeHTTP. And an entire Pushup app is just a http.ServeMux too. So it should be trivial to insert middleware (although there isn't Pushup syntax for that yet), and/or embed a Pushup app in a larger Go app (this is quite possible today).

geenat 4y ago

>It works well early but has scaling problems over time. How? Otherwise calling this out as cargo cult. As I remember the main reason we moved to app routing is because of the single process nature of non-blocking async code which was popularized with node / express.