4 ms·

As someone who dabbled in PHP but is mostly a self-taught JS hobbyist dev, I have been using and loving Directus (https://directus.io https://directus.io) since

As someone who dabbled in PHP but is mostly a self-taught JS hobbyist dev, I have been using and loving Directus (https://directus.io https://directus.io) since around the time they switched to Node. Development velocity is exceptional with new features released every couple of weeks and bugfixes/enhancements even more frequent, the community and core team is fantastic, and I like the fact that if I ever decide to switch to another CMS for some reason, there's no real import/export process, I just delete the directus_tables in my database, and done. Pocketbase (https://pocketbase.io/ https://pocketbase.io/) piqued my interest after seeing it here and on ProductHunt, but I don't think it would be the right call for a client before it hits a stable release. I also very much enjoyed OctoberCMS (although it has its quirks), but there was a fairly acrimonious split in the community there, and OctoberCMS is no longer open source, and I haven't used the fork (WinterCMS: https://wintercms.com/ https://wintercms.com/) I enjoyed using Apostrophe (https://apostrophecms.com/ https://apostrophecms.com/) for a while, but ultimately I felt like I was doing a lot of stuff in a way that didn't come naturally to me, and although Mongo seems a logical choice when you look at Apostrophe's page model, it worried me a bit that the data would not be easy to move if I ever wanted to.

likortera 4y ago
I really wish directus had a simple "cookie" based auth, and not all this crazyness with a cookie + refresh token + renewals + refresh + JWTs +... I was trying to use it with Next.js, where I needed to authenticate the current user server side to fetch some data and it was by far the most overcomplicated part of my application. We ended up switching to Django, where just an traditional http only secure cookie which we "proxied" from Next.js to the frontend and back was enough and maybe even more secure than all the mangling we had to do with the refresh tokens, etc. I really wish this trend of fancy authentication mechanisms goes away. It doesn't take in account how easy they make for people to mess up on their implementation/usage of it when things are too complex.
- d1sxeyes 4y ago
  I feel you there - I do always feel like I'm writing a lot of code for something that should be better abstracted away - if I send a u/n and p/w once, then I should be logged in until I log out (or my session is invalidated server-side), and I'm always worried that that doesn't happen properly when I use the SDK. I THINK it does, but I got burned once when it broke last year around the 9.0.0 update, and now I struggle to trust it... I tend to end up doing something like this: https://github.com/directus/directus/discussions/10101 https://github.com/directus/directus/discussions/10101
  - likortera 4y ago
    Yeah, that's the point. I think the SDK is not that helpful when running code in the backend (SSR). What frustrates me is that I don't get what's wrong with just using the traditional http-only secure cookie backed by a server side session. That just works, and it's one of the most safe ways to do it. Even banks do it that way. All the JWT temporary refresh token whatever sounds like somebody was just bored and wanted to have fun. Sorry, I was pretty burned out about this. So much that we ended up swapping it for something else.

likortera 4y ago

I really wish directus had a simple "cookie" based auth, and not all this crazyness with a cookie + refresh token + renewals + refresh + JWTs +... I was trying to use it with Next.js, where I needed to authenticate the current user server side to fetch some data and it was by far the most overcomplicated part of my application. We ended up switching to Django, where just an traditional http only secure cookie which we "proxied" from Next.js to the frontend and back was enough and maybe even more secure than all the mangling we had to do with the refresh tokens, etc. I really wish this trend of fancy authentication mechanisms goes away. It doesn't take in account how easy they make for people to mess up on their implementation/usage of it when things are too complex.

d1sxeyes 4y ago
I feel you there - I do always feel like I'm writing a lot of code for something that should be better abstracted away - if I send a u/n and p/w once, then I should be logged in until I log out (or my session is invalidated server-side), and I'm always worried that that doesn't happen properly when I use the SDK. I THINK it does, but I got burned once when it broke last year around the 9.0.0 update, and now I struggle to trust it... I tend to end up doing something like this: https://github.com/directus/directus/discussions/10101 https://github.com/directus/directus/discussions/10101
- likortera 4y ago
  Yeah, that's the point. I think the SDK is not that helpful when running code in the backend (SSR). What frustrates me is that I don't get what's wrong with just using the traditional http-only secure cookie backed by a server side session. That just works, and it's one of the most safe ways to do it. Even banks do it that way. All the JWT temporary refresh token whatever sounds like somebody was just bored and wanted to have fun. Sorry, I was pretty burned out about this. So much that we ended up swapping it for something else.