I have some projects with a fairly steady load that I'm currently running on a VPS on Digital Ocean. I have some non-critical ones that I'd be interested in moving to "bare metal" for learning purposes, but having a hard time figuring out what the transition from VPS to dedicated server would look like.
Anybody have any guides or guidance on making the migration? I feel comfortable managing the VPS, but not sure what else I'd need to take on by moving to a dedicated server. I imagine hardware monitoring would be one, but what else?
My youngest is absolutely obsessed with construction trucks. We really love the "Construction Site" series by Sherri Duskey Rinker. Some of the later books in the series go into how roads are built, airports, etc. Really lots of fun for anybody else who has little ones interested in construction. https://www.goodnightconstructionsite.com/
If you haven’t yet, you should try out usage_rules mix package. I mostly use Ash, which has great support for usage rules and it’s a night and day difference in effectiveness. Tidewave is also really nice as an MCP as it lets the agent query hexdocs or your schema directly.
A bit late but it’s been fantastic so far. I’m using it for a GraphQL backend so I haven’t tried with LiveView yet but I don’t think it’ll differ too much. I know Ash has their own changesets which might be a bit different, but can’t say for sure.
In general Ash has a rough learning curve, but it helps a LOT for what I think Phoenix is missing or isn’t opinionated about which is the context layer. Ash basically builds that for you, and probably better and more secure than you can do yourself.
The way I see it, a LiveView to display data might do something like MyContext.fetch_items(scope: socket.assigns.scope). All Ash does is derive those functions for you. So maybe you have MyDomain.fetch_items(actor: socket.assigns.user)
But then if you want filtering, sorting, etc that’s all there for you, while you’d have to build that yourself with Ecto. But then did you remember to filter your joins to only retrieve the items the user is authorized to see? Sure, you can do that in Ecto, but it’s kinda just built in with Ash policies.
I hope that helps - Ash doesn’t replace anything that Phoenix or LiveView offer (except maybe changesets are slightly different), it very much builds on top of it.
Edit to add, Ash is built on top of Ecto. The escape hatches are there, and easily accessed if needed. Ash.Query is very powerful and I haven’t needed any escape hatches on a small to medium sized project so far.
Very cool to see usage_rules mentioned in the blog. That tool is such a great idea, and leveraging that for Ash development has made a drastic improvement in LLM development for me. Excited to see that get more adoption across the Elixir ecosystem.
I use Tidewave which is a package for my Elixir app, and it allows the LLM to get access to some internals of my app. For example, Tidewave exposes tools to inspect the database schema, internal hex documentation for packages, introspection to see what functions are available on a module, etc.
While I’m not “vibe” coding, it is nice to be able to ask human language questions and have the LLM query the database to answer questions. Or while working on a feature, I can ask it to delete all the test records I created, etc. I can do that in a repl myself, but it’s sometimes a nice shortcut.
Note, this only runs in dev, so it’s not querying my production database or anything.
Basically, they can be a way to expose additional data or tools to the LLM.
I guess, but you'll be writing a _lot_ of code yourself, that might be hard to maintain and can become brittle overtime as requirements evolve.
As an example, I wanted to add support for adding tags to a resource, and support filtering for the resource by the tag, and I wanted to be able to do this filtering both through Elixir functions as well as GraphQL.
Can I do this with Ecto? Absolutely, but I'd have to build it all myself.
With Ash, I created a `Tag` and `Tagging` resource, adding a `many_to_many` block on my resource, marked it as public. Then I added the `AshGraphql.Resource` extension to my `Tag` resource, marked it as filterable and I was done.
Now I can filter and sort by tags, filter by where tags _don't_ exist and more. I didn't have to do anything other than model my domain, and Ash took care of the rest for me. Not only that, but it probably did a lot of things for me that I probably wouldn't have thought of, such as supporting multi-tenancy, policies and more.
It really is a lovely tool, I can't say enough good things about it.
Does it have a learning curve? Absolutely! Is it worth overcoming it? Again, absolutely!
My current project is using React Native (for native and web) and getting GraphQL setup was initially a pain, but having React and GraphQL subscriptions gives me enough of the "live" functionality, but without having to worry about connection issues. With gql-tada, I get fully typed experience on the front-end too.
Yes, the learning curve is a extremely high. It took a few false starts over time, but after the "Ash book" came out, I gave it a more serious try and it finally started to click for me.
I think it helped that at the time I was trying to build some pretty advanced filtering functionality using Ecto and was having a pretty tough time. While searching for solutions I saw a few mentions of Ash and that it could solve the problem out of the box.
After a few days of experiments, I found that it was able to do the filtering I wanted out of the box and was even more functional than what I was trying to build.
For reference, I was trying to add some tagging functionality to a resource and I wanted to be able to filter by that tag, including multiple tags. Can I do that in Ecto? Of course, but Ash provided that out of the box after modeling the resource.
I've been using Elixir for about a year on a side project and I've been enjoying it more than any other backend I've used (Node, Rails and C#). I recently discovered Ash and I feel like after that initial learning curve my productivity (and code quality) has improved quite a bit.
I wish Elixir had more mindshare beside just LiveView and "real time" type functionality. Even building a GraphQL/JSON endpoint without real-time requirements, the functional nature (no side effects), pattern matching and ruby inspired syntax makes writing plain old JSON controllers a joy.
While Elixir might not have a package for every use case under the sun, the low level primitives are there.
Claude Code has pretty much replaced Copilot overnight for me, though I wish the VS Code plugin was a bit more integrated, as it's only a little bit more than a terminal, though I guess that's the point. I was hoping for syntax highlighting to match my editor and things like that (beyond just light/dark theme).
What I'd really want is a way to easily hide it, which I did quite frequently with Copilot as its own pane.
I absolutely loved EverQuest and it’s still probably holds some of my fondest gaming memories. My favorite feeling about it is that it felt like a real world first, gameplay second. It had a real sense of danger and wonder that I think will be almost impossible to recreate.
Going from Qeynos to Freeport, or crossing the ocean on a boat felt absolutely epic and dangerous. It was wonderful, but not something I would want to play today now that I have real life obligations.
The GraphQL layer is built on top of Absinthe. If you really find something you can't model with Ash's actions, you can always just jump to your Absinthe schema and write you own queries/mutations/subscriptions. You'll just need to write your own resolver.
I've been working on a project for a few months, and I had some of those initial pain points early on as well. I've actually found the codebase surprisingly approachable and have found the team to be very open to bugs and merging PR's. Many times I've created a bug report, and within a day, it's been fixed, or within a day I was able to track down the bug and open a PR to fix it.
Maybe it's just me, but I found the Ash (and ecosystem) codebase a lot more approachable than something like Rails.
The first few weeks on the project were tough, and the documentation challenges are certainly there, but they get better day by day.
After getting comfortable and accepting the "Ash" way, I've found my productivity to skyrocket when using Ash to build an Absinthe GraphQL api. Previously I'd have to build the context layer, then the resolvers, etc.
Now with Ash, I write my action, declare my query/mutation/subscription and get all the rest for free. I can't see myself going back to writing Elixir apps without Ash.
I'm also very comfortable with Phoenix and Ecto (and LiveView), and initially found Ash a challenge to wrap my head around. After working through the book and really keeping an open-mind on my next project, I've found it a real joy to work with.
Keep in mind that Ash doesn't really replace Phoenix or LiveView (or Ecto), but it's built on top of it. You can still use Phoenix and LiveView the same way you are today, and just rely on Ash to build your context for you and how you interact with your resources. So I'd say it "replaces" Ecto in that sense (though it's all Ecto under the hood).
For me, I'm building a native app with a GraphQL backend and it has been an amazing productivity increase. With Ash, GraphQL on the backend and React and gql.tada (https://gql-tada.0no.co/) on the front-end providing a fully typed experience, I feel even more productive than using LiveView.
As a quick example - I have an existing derived GraphQL endpoint with a query for getting a resource, and I can have basic filters and sorting out of the box from Ash (i.e. filter by status, sort by name, filter by date greater than X, etc.)
Recently, I needed to build a feature to support adding a tag to a resource. I modeled the relationships (join models, etc.), made the necessary additions to my create/update actions and without _any_ changes to my GraphQL setup, I was able to support filtering my resource by tag (or tags) basically for free.
Can I build that in Ecto directly within my Phoenix context? Of course, but I didn't need to - Ash derived that functionality for me, and built that in, with all of the necessary preloading through dataloader and all of that for me, so the queries are optimized.
Ash is a huge mindset shift, and I think it'd be tough to incorporate it into an existing project, but if you're able to start a new project from scratch, I really recommend you give it an honest try. Especially if you think you might need to have additional data channels (i.e. LiveView and GraphQL or Json API).
I wouldn't let the fact that the book is in beta dissuade you from getting it. It's mostly feature complete and is a _fantastic_ resource - it really helped get Ash to click for me, and I've found it a joy to work with after getting that initial ah-ha moment.
I know the Ash team is aware of the documentation challenge, and they are working on it. I feel like the book is an answer to that, and hopefully a lot of the greatness of the book is able to make its way back to the docs.