I spent the last week adapting the build of my project to Obelisk. I find it (and the reflex-platform build) to be unnecessary convoluted, but I've figured most of it out now. Would be interested in hearing some other opinions
Yeah, I pretty much use obelisk for all my reflex these days. Having the frontend routing and typesafe static file handling all sorted for you is nice enough win as it is. Some semblance of server side rendering is also nice.
I find myself needing much deeper changes, examples being the use of base-noprelude and having includes and defaults in my hpack files. I reimplemented the whole ghcid ob run setup in nix…I think it would be more sensible to separate the web component from the rest of the project and sticking to the frontend/backend/common structure
I'd say it's possible to be opinionated and still keep the build nix expressions flat enough for people to slightly deviate from the default without contortions :smiley:
One thing I'd like to do today is to use something like Firebase, so I can write my SPAs without bothering to setup backend. There is https://github.com/JBetz/reflex-firebase
Like, if I want to quickly prototype a small app to count workout reps for myself I can just spin up an obelisk project template pre-using reflex-firebase and finish it a couple of hours.
me waiting for some more info on this as well :D - since it was mentioned in the Reflex-FRP already, I spoil here (not working for obsidian :D): IV stands for incremental view and it was also already presented in a zurihac talk by Ryan (and another talk, both lost :/ and my memories also lost despite I liked the zurihac talk :D). But it is not official yet, so we have to be patient.
@Sridhar Ratnakumar yeah I do. No need to be secretive about IV. It'll be public when its ready, but there is a long process going on hidden to make sure that it is ready so that we don't release something and then whipsaw people having to make drastic changes to it later. It's getting there, but it's definitely still experimental. It's not as dependent on vessel as you'd think.
I have a weird situation with ghcide and neovim, maybe one of you has an idea: when ghcide starts while I have a haskell file open, its cwd is set to the root of the module (e.g. frontend), and it looks for hie-bios.sh there. if the currently edited file is of another type, the project root is cwd.
You are doing great stuff here Sridhar! :) ... meanwhile I did, based on the something project, use rhyolite to show a map, put pins on it, move them around -- and replaced beam with persistent (didnt like the API too much :) ). Let's see if I can convince a customer to use it, otherwise I will make it available as well :D .
You are doing great stuff here Sridhar! :) ... meanwhile I did, based on the something project, use rhyolite to show a map, put pins on it, move them around -- and replaced beam with persistent (didnt like the API too much :) ). Let's see if I can convince a customer to use it, otherwise I will make it available as well :D .
But having been briefly in the latest video chat and hearing the not motivating example by one the guys, I assume this will probably also happen to me :D :D (but dont want to change the topic here ;) )
Quick question: For deploying to AWS I would need the real connection string to an RDS - Is there some nix/obelisk way to set an env var so the app knows what to connect to? So assuming release.nix is there for some reason.
Be a little careful with rhyolite and it's public but purposefully not publicised state. It will end up being deprecated by IV sometime soonish so I wouldn't use rhyolite in a work project. But it's definitely a fun experience to see how well a QueryT / RequeserT based reflex app can work.
And if you don't like beam, you're gonna hate IV, lol.
thanks for the hint regarding deployment and the primer regarding IV+beam :D , maybe I switch back to beam :D :D (no wasted time so far, I am learning a lot along the road). But I assume beam is just the preferred choice but not necessarily hard wired to IV?
Any primer on "how hard" to switch to IV from the Rhyolite way?
"Soonish" is a little bit to far away, guess I need to make my point pretty soon. The better if the proper solution comes somewhere on the way :D .
Yeah, that's why I'd advise caution. There's no real way to know whether rhyolite is deprecated next month or next year at this point. But it was already a bit of an unpolished tool box of bits to add onto Obelisk and it'll certainly get worse if Obsidian things move on, lol.
It's going to be a big shift. Instead of writing your view selectors and notification handlers yourself IV knows way more about the database and being able to push updates into the db and let other things know what changed. Beam isn't irreparably baked in there, but it is the first thing that was targeted because it was deemed the most appropriate. You could write another thing, but that could be a lot of work. You certainly wouldn't do that while you were learning the thing.
I don't really know how big of an effort the migration would be given I'm only following IV from the outsides, but I'd think that it would be safe to say that if your model was already in beam rather than esqueleto, it'd be a whole lot easier.
If your backend model was in beam, I'd say expect to have to learn a bunch of stuff and rewrite everything in your view selectors / notify handler and request handler.
It was all in Ryan's head for a long time after that, but it has recently (a few months) exited out of that state and there are a bunch of people on it. But there's the long road of making it fast, fixing memory leaks, getting it nice to use, etc.
I imagine Cale Gibbard might have had his hand in it as well, as he usually does in the various projects and libraries at Obsidian. Man, I enjoyed pairing with Cale even if only briefly. One of the things I miss right now.
I have a weird situation with ghcide and neovim, maybe one of you has an idea: when ghcide starts while I have a haskell file open, its cwd is set to the root of the module (e.g. frontend), and it looks for hie-bios.sh there. if the currently edited file is of another type, the project root is cwd.
FYI! problem was that package.yaml was in coc.nvim's rootPatterns config option, and the subpackage contained one of those.
Are there many people here using Obelisk or Reflex?
I want to make a project of this, I was thinking of doing so this weekend
I spent the last week adapting the build of my project to Obelisk. I find it (and the reflex-platform build) to be unnecessary convoluted, but I've figured most of it out now. Would be interested in hearing some other opinions
Purescript works really well too.
My GitHub has some obelisk projects
Yeah, I pretty much use obelisk for all my reflex these days. Having the frontend routing and typesafe static file handling all sorted for you is nice enough win as it is. Some semblance of server side rendering is also nice.
do you customize the build a lot?
What kind of customisation? Haskell overrides? Yeah that's pretty normal.
I find myself needing much deeper changes, examples being the use of
base-nopreludeand having includes and defaults in my hpack files. I reimplemented the whole ghcidob runsetup in nix…I think it would be more sensible to separate the web component from the rest of the project and sticking to the frontend/backend/common structureghcide and docker support are also currently fresh in experimental branches, I use both but it needs a lot of tweaking
No webserver is basically reflex-platform.
Just without the cli tool to run it.
But yeah. Obelisk is opinionated. If you have different opinions, you'll probably have to peel things back and roll your own.
I'd say it's possible to be opinionated and still keep the build nix expressions flat enough for people to slightly deviate from the default without contortions :smiley:
what do people use to fetch data from the backend? I've seen
servant-reflexbut I'm wondering if there's anything built into obelisk?IV?
intravenous? please elaborate, @Sridhar Ratnakumar :smiley:
@Ben Kolera How much permission do we have from Obsidian as to talking more about it? :-)
does everyone here work at Obsidian? :joy:
One thing I can tell right now is that it is going to be awesome.
I did, in the past.
well now I want to know more
so I'll have to stick with servant-reflex until Untitled Mystery Project IV is released?
One thing I'd like to do today is to use something like Firebase, so I can write my SPAs without bothering to setup backend. There is https://github.com/JBetz/reflex-firebase
interesting
Like, if I want to quickly prototype a small app to count workout reps for myself I can just spin up an obelisk project template pre-using reflex-firebase and finish it a couple of hours.
I think it would be a good template repository. You can remove
./backendand./commonand simplify things a lot.Torsten Schmits said:
me waiting for some more info on this as well :D - since it was mentioned in the Reflex-FRP already, I spoil here (not working for obsidian :D): IV stands for incremental view and it was also already presented in a zurihac talk by Ryan (and another talk, both lost :/ and my memories also lost despite I liked the zurihac talk :D). But it is not official yet, so we have to be patient.
@Sridhar Ratnakumar yeah I do. No need to be secretive about IV. It'll be public when its ready, but there is a long process going on hidden to make sure that it is ready so that we don't release something and then whipsaw people having to make drastic changes to it later. It's getting there, but it's definitely still experimental. It's not as dependent on vessel as you'd think.
Can I be a beta tester?
There has been two talks on it, but it is cursed and somehow both talks lost their video.
I'm not on the IV team so I can't make such calls. But my guess would be that it is still a bit early for alpha testers. :slight_smile:
I think right now it is being internally alpha tested sorting out the memory leaks, getting the api good, etc.
Experimental ghcide support https://github.com/obsidiansystems/obelisk#experimental-ghcide-support
yup, works pretty well for me
I have a weird situation with ghcide and neovim, maybe one of you has an idea: when ghcide starts while I have a haskell file open, its
cwdis set to the root of the module (e.g.frontend), and it looks forhie-bios.shthere. if the currently edited file is of another type, the project root iscwd.No idea sorry.
https://github.com/srid/obelisk-rhyolite-template
Sridhar Ratnakumar said:
You are doing great stuff here Sridhar! :) ... meanwhile I did, based on the
somethingproject, use rhyolite to show a map, put pins on it, move them around -- and replacedbeamwithpersistent(didnt like the API too much :) ). Let's see if I can convince a customer to use it, otherwise I will make it available as well :D .Matthias Putz said:
But having been briefly in the latest video chat and hearing the not motivating example by one the guys, I assume this will probably also happen to me :D :D (but dont want to change the topic here ;) )
Sridhar Ratnakumar said:
Quick question: For deploying to AWS I would need the real connection string to an RDS - Is there some nix/obelisk way to set an env var so the app knows what to connect to? So assuming
release.nixis there for some reason.Be a little careful with rhyolite and it's public but purposefully not publicised state. It will end up being deprecated by IV sometime soonish so I wouldn't use rhyolite in a work project. But it's definitely a fun experience to see how well a QueryT / RequeserT based reflex app can work.
The configuration like that is wrapped up in ob deploy @Matthias Putz .
If you grab the configuration from the obelisk config, then when you deploy an obelisk app you can give it config then.
And if you don't like beam, you're gonna hate IV, lol.
Ben Kolera said:
thanks for the hint regarding deployment and the primer regarding IV+beam :D , maybe I switch back to beam :D :D (no wasted time so far, I am learning a lot along the road). But I assume beam is just the preferred choice but not necessarily hard wired to IV?
Any primer on "how hard" to switch to IV from the Rhyolite way?
"Soonish" is a little bit to far away, guess I need to make my point pretty soon. The better if the proper solution comes somewhere on the way :D .
Yeah, that's why I'd advise caution. There's no real way to know whether rhyolite is deprecated next month or next year at this point. But it was already a bit of an unpolished tool box of bits to add onto Obelisk and it'll certainly get worse if Obsidian things move on, lol.
It's going to be a big shift. Instead of writing your view selectors and notification handlers yourself IV knows way more about the database and being able to push updates into the db and let other things know what changed. Beam isn't irreparably baked in there, but it is the first thing that was targeted because it was deemed the most appropriate. You could write another thing, but that could be a lot of work. You certainly wouldn't do that while you were learning the thing.
I don't really know how big of an effort the migration would be given I'm only following IV from the outsides, but I'd think that it would be safe to say that if your model was already in beam rather than esqueleto, it'd be a whole lot easier.
If your backend model was in beam, I'd say expect to have to learn a bunch of stuff and rewrite everything in your view selectors / notify handler and request handler.
Probably also some tweaks to frontend types too, but it's probably a lot the same just sending a query and requests.
@Ben Kolera I was there when the chess app was being demo'ed (this was last year I think), but I don't know how far IV has progressed since then.
It was all in Ryan's head for a long time after that, but it has recently (a few months) exited out of that state and there are a bunch of people on it. But there's the long road of making it fast, fixing memory leaks, getting it nice to use, etc.
I imagine Cale Gibbard might have had his hand in it as well, as he usually does in the various projects and libraries at Obsidian. Man, I enjoyed pairing with Cale even if only briefly. One of the things I miss right now.
Torsten Schmits said:
FYI! problem was that
package.yamlwas incoc.nvim'srootPatternsconfig option, and the subpackage contained one of those.I can haz some feedback on this draft blog post on obelisk? https://www.srid.ca/fa9766e6.html
why is
ob runlike ghcid when it actually uses ghcid?Good catch; I guess I was thinking of the reflex-ghci port, which has not been released yet. Fixed
you're using the term "git rep", is that an abbreviation I've missed so far or did you intend to write "repo"? :smile: