Check out the Ash framework that's built on top of Phoenix+Elixir.
Ask HN: Hunting for a Framework
51–60 of 70 posts
Re: Ask HN: Hunting for a Framework
#52Earlier quoted context omitted.
I could not disagree more — allowing a third party to own the most crucial data in your app (the users) is a big mistake. I’ll admit to only having experience with Firebase for third-party auth, but in my experience the drawbacks of splitting auth and user related code between two systems soon outweighs the benefits of getting up and running quickly. Auth code is undifferentiated, but if you have experience building…
I want to disagree with both of you - the sweet spot is often 3rd-party authN, 1st-party authZ: * don’t try to implement the hard/annoying bits (strange access detection, account recovery, sending emails, password storage) * keep ownership of your user list and users’ capabilities
I disagree with all three of you.
It depends on the use case.
Re: Ask HN: Hunting for a Framework
#53https://github.com/elide-dev/v3
it's very early but we have the same goals. especially your point about central schema.
Re: Ask HN: Hunting for a Framework
#54I'm working on a framework in Ruby that uses Haml for templating. It is inspired by React and has a VDOM, but it's 100% server side and DOM-patches are streamed to the browser as state updates on the server. Callback handlers are just POST-requests and they are set up like this: ruby: def self.get_initial_state(initial_count: 0, **) = { count: initial_count } def handle_click update do |state| { count: state[:count]…
I’m pretty sure there will be interest in this. I like working with FE frameworks but a lot of Rubyists don’t. Ideally many devs just want to work with haml/slim/erb and have an interactive UI without any writing any JS. Your example is really nice because it avoids an entire layer of FE state management / synchronisation. Not sure how much overlap there is with Hotwire as I haven’t really looked into it yet.
Re: Ask HN: Hunting for a Framework
#55I love reading the comments. There are no simple answers. I was and still am in a similar situation. Since performance, ease of use and resource consumption are important my backend language of choice is Go. So I wrote a simple backend generator with RESTful CRUD endpoints. The workflow is, you define the data models in your models package. The generator then analyzes those models, creates all the routes and reposito…
Hey, I am the creator of entgo.io. I'm sorry to hear that your experience with the project was not great. I try to be available on our Discord, Slack, or the issue tracker, but sometimes I do miss some messages. If you ever consider to rejoin the community, please don't hesitate to drop me a message on our Discord.
I would also like to emphasize that Ent is an open-source project under the Linux Foundation, and it is not monetized in any way. Most of my work on it in the last years was on my free time, including when I was working at Facebook and wanted to OSS it. We (heavily) use Ent in our own products today, and that is why we continue to sponsor and maintain the project. I love it and I find it useful.
Thanks for the honest feedback. I appreciate it.
Re: Ask HN: Hunting for a Framework
#56Not a framework but I'm tinkering with the following stack: 1. Hasura - DB + Basic APIS 2. Ory.sh for Auth/Authz 3. React on the frontend 4. Windmill.dev for Scheduling/Batch processing/ Background tasks 5. Docker for deployment 6. Fastify + Node JS for glue code (can use Windmill for Glue code too) I have used Hasura extensively at 2 companies. It's well done and saves a ton of time. You might also want to look at R…
I am loving Hasura so far. However, I am getting stuck with how to best write custom logic on top of this. For example: I have a products table, which Hasura will automatically generate schema for. But now I want to do a custom getProducts GraphQL query to do more advanced filtering (search, sort, ranking etc). What I end up doing it to have a remote schema. And now my clients need to understand two different product types (one generated by Hasura, and one generated by my custom remote schema. Do you have any advice on how to best resolve this?
On top of that, do you typically parse these Hasura Apollo into your client models? Or do you use the fragments directly in UI code since it already support types.
Re: Ask HN: Hunting for a Framework
#57I'm working on a framework in Ruby that uses Haml for templating. It is inspired by React and has a VDOM, but it's 100% server side and DOM-patches are streamed to the browser as state updates on the server. Callback handlers are just POST-requests and they are set up like this: ruby: def self.get_initial_state(initial_count: 0, **) = { count: initial_count } def handle_click update do |state| { count: state[:count]…
I’m pretty sure there will be interest in this. I like working with FE frameworks but a lot of Rubyists don’t. Ideally many devs just want to work with haml/slim/erb and have an interactive UI without any writing any JS. Your example is really nice because it avoids an entire layer of FE state management / synchronisation. Not sure how much overlap there is with Hotwire as I haven’t really looked into it yet.
Check it out if you want, https://github.com/mayu-live/framework
It's far from production ready, but it's already working reasonably well.
I tried HotWire but it didn't feel right to me because I'm used to React.
Re: Ask HN: Hunting for a Framework
#58Remix, zod, tRPC(if/when API endpoints are needed), Typescript, Prisma. This stack is gorgeous. Same language and type definitions front to back is a game changer. The realtime aspect of what you are looking for is the hard part. The only options I know of are the remix stack above (you still have to do some extra plumbing), elixir/Phoenix (or other turbo links like options but most aren't fast enough). To do realtim…
Aside from replacing Remix with Next.js, this is also what I would recommend. Remix makes things that were simple hard (apparently with the goal of doing _everything_ on the server again).
I can speak to a handful of things Remix needs to improve, but "makes things that were simple hard" is a very big generalization. Remix nets out for me big time. I've never been as productive with another framework. Also, remix does SSR but so do a lot of frameworks, is that what you mean when you say "__everything__ on the server again"??
Re: Ask HN: Hunting for a Framework
#59Not a framework but I'm tinkering with the following stack: 1. Hasura - DB + Basic APIS 2. Ory.sh for Auth/Authz 3. React on the frontend 4. Windmill.dev for Scheduling/Batch processing/ Background tasks 5. Docker for deployment 6. Fastify + Node JS for glue code (can use Windmill for Glue code too) I have used Hasura extensively at 2 companies. It's well done and saves a ton of time. You might also want to look at R…
I am loving Hasura so far. However, I am getting stuck with how to best write custom logic on top of this. For example: I have a products table, which Hasura will automatically generate schema for. But now I want to do a custom getProducts GraphQL query to do more advanced filtering (search, sort, ranking etc). What I end up doing it to have a remote schema. And now my clients need to understand two different product…
Hm…ideally your remote schema can return one or more product ids and then you can create a relationship back to the model from
Postgres.
Link to docs: https://hasura.io/docs/latest/remote-schemas/remote-relation...
Re: Ask HN: Hunting for a Framework
#60RedwoodJS seems to tick the boxes although I'm not super clear on the real-time aspect. I don't see it from scanning the docs. I think RedwoodJS has to be tried given your requirements. Personally, I'd say go with Supabase, and then try SvelteKit or use React/next.js. Supabase handles the data access, mails the real-time, and bakes in auth in the right way. Decoupling the front end lets you choose and adapt the right…
The Supabase CLI does have migrations (merge-diff approach that is wonderful) and codegen for DB types for the front-end to use. We've even dispensed with Prisma recently as the ORM and just use the Supabase Client for data access on the front-end. Whole API layer disappears. Add in a SvelteKit and deploy to a Vercel and you have a minimal yet powerful stack with everything you need for 90% of business CRUD app deman…
I agree with the usefulness of supabase. A product we built moved quickly with supabase. But as product(s) mature, you inevitability have to create api routes that can perform sql transactions, call other apis, and do basically any other special work that the supabase client can’t do.
I still prefer keeping almost all work server side but then load it in the client ala remix/sveltekit loader style. This means I don’t have to build an API at all. Unless it’s a backend for a native client app (mobile, desktop, tv).