3 ms·

I've been tinkering with redwood.js for the last couple of months. I quite like it and it definitely speeds things up, compared to rolling out everything yourse

by iyn 6y ago

I've been tinkering with redwood.js for the last couple of months. I quite like it and it definitely speeds things up, compared to rolling out everything yourself. But since this is alpha-grade, there have been a lot of breaking changes -- which I totally understand, but it's been PITA to work on upgrades vs my side project. To the point: how does the upgrade situation looks like with Blitz.js? What are the plans for breaking changes now that's in a beta? Also, what would be the biggest differences between redwood & blitz (besides blitz being based on next)? Lastly, thank you for working on this project/problem, definitely a lot of potential here. I've also seen that you really care about the community around the project, which is awesome!

flybayer 6y ago
We expect only minimal breaking changes to Blitz from here on. 1.0 is expected in April. The biggest difference between Blitz and Redwood is that Redwood makes the API layer easier with conventions and APIs, whereas Blitz abstracts away the entire thing into a compile step. So working with Redwood requires working with APIs like normal. But with Blitz you can almost forget an API is even there.
- iyn 6y ago
  Thanks, 1.0 being just around the corner definitely makes me more interested! As for the redwood vs blitz, I think I get what you're getting at but still not fully grok what _exactly_ it means/looks like (and what are the tradeoffs). I'll experiment with it, so I can develop the intuition myself :).
- snarkypixel 6y ago
  "But with Blitz you can almost forget an API is even there." How does it work for clients using an old version of the app? I.e. if I change the db schema and update it for new clients, what will happen to older clients?
  - flybayer 6y ago
    It works the same as any other fullstack web app (possibility for discrepancies). We'll add a hook/API that allows you to easily detect if a new version is deployed and handle this gracefully by e.g. notifying the user. I'd also like to go even further and add some type of detection to the build that would notify you of potential issues.
    - kevincox 6y ago
      Notifying the user isn't graceful. "Hi, we can't handle any version skew so please interrupt what you are doing to click this button and reload the app."
    - cwackerfuss 6y ago
      makes sense. could also explore versioned routing, where you detect multiple versions based on filename (e.g. *_v1), folder name, or some export naming convention.
      - flybayer 6y ago
        Yes, good idea!

by iyn 6y ago

flybayer 6y ago

We expect only minimal breaking changes to Blitz from here on. 1.0 is expected in April. The biggest difference between Blitz and Redwood is that Redwood makes the API layer easier with conventions and APIs, whereas Blitz abstracts away the entire thing into a compile step. So working with Redwood requires working with APIs like normal. But with Blitz you can almost forget an API is even there.

iyn 6y ago
Thanks, 1.0 being just around the corner definitely makes me more interested! As for the redwood vs blitz, I think I get what you're getting at but still not fully grok what _exactly_ it means/looks like (and what are the tradeoffs). I'll experiment with it, so I can develop the intuition myself :).
snarkypixel 6y ago
"But with Blitz you can almost forget an API is even there." How does it work for clients using an old version of the app? I.e. if I change the db schema and update it for new clients, what will happen to older clients?
- flybayer 6y ago
  It works the same as any other fullstack web app (possibility for discrepancies). We'll add a hook/API that allows you to easily detect if a new version is deployed and handle this gracefully by e.g. notifying the user. I'd also like to go even further and add some type of detection to the build that would notify you of potential issues.
  - kevincox 6y ago
    Notifying the user isn't graceful. "Hi, we can't handle any version skew so please interrupt what you are doing to click this button and reload the app."
  - cwackerfuss 6y ago
    makes sense. could also explore versioned routing, where you detect multiple versions based on filename (e.g. *_v1), folder name, or some export naming convention.
    - flybayer 6y ago
      Yes, good idea!