Fork me on GitHub
#untangled
<
2017-03-01
>
tony.kay01:03:23

NOTE: Untangled client 0.7.1-SNAPSHOT is on clojars, and has multiple remote support, along with an expanded defmutation that can deal with multiple remotes. I've tested it on the single-remote code, but not yet on the multiple (but it is all the same code paths, so it should work). I'd be really interested if anyone finds breakage (i.e. it should be 100% backward compatible).

tony.kay04:03:00

I'm thinking about some simplifications towards a 1.0 release, with the following goals in mind: 1. Merge the modular server hooks, i18n string extractions/tools, and client together into just "untangled". This would eliminate a lot of the external deps, and reduce deployment size (uberjar). 2. Move the sample server construction to the template, using the new modular support. This would be the most flexible, since it would be ring and a web server in the template, not in Untangled. 3. Fix up all the docs. 4. Add clojure.spec specs to everything in the library Some of these steps are bigger than others. (1) is actually relatively simple, and would let us "clean house" on various cruft, since it would be a new combined library. (2) is similarly small. (3) is probably the biggest task, and (4) is a nice-to-have. I'd be interested in thoughts if anyone has them.

tony.kay04:03:25

Drop the "web framework" part of the title.

tony.kay04:03:26

It's a relatively light library when we do that, which I find more attractive. The newer, more compositional, server stuff is way more attractive as well. The i18n stuff moving into the main library also makes it easier to write boot tasks or just clj scripts to do the i18n manipulations. Gives us more flexibility on build systems.

qqq05:03:24

@tony.kay : (1) would be amazing, I'd definitely test it out; though I'm really starting to prefer the datascript model to the om/next db model

qqq05:03:43

imho, the other thing that would also really really help win over users, would be end to end solutions

qqq05:03:12

in addition to one-line herko deploy, it'd be nice if we also had one-line gae + one-line aws deploy

qqq05:03:23

I can help out with the one-line gae deploy

tony.kay05:03:28

@qqq glad to take contribs

qqq05:03:53

already does client, server, network; so we might as well as go one step further and handle minimal deployment too

qqq05:03:22

okay; so it'd be two lines; isntead of "git push heroku master", it should be reducable to: "lein uberwar" "dev_appserver.sh deploy path-to-war" [wait 10 minutes]

qqq05:03:44

hmm, this may also provide an incentive for you to slim down the server side if you can see how annoying the 10 min wait is 🙂

tony.kay05:03:24

I'm dropping the server side, as far as web server. The clojurescript dep also needs to be a dev dep, which was part of why it is so big

tony.kay05:03:52

the server side will just be something you can hook into your own server as you see fit. Pregen server will be in template, where it belongs

qqq05:03:55

@tony.kay: I'm grateful for all the time you helped me understand untangled/om-next; in return, I'd like to give back a minimal untangled-gae setup, regardless of how long it takes to deploy. The question is (1) should I do this now or wait until 1.0 comes out and (2) if now, what template should I start with?

qqq05:03:18

Oh, gae doens't support websockets

qqq05:03:27

so the code I start with has to be rest based and not need datomic

tony.kay05:03:01

@qqq that sounds good. You could wait. websockets not an issue. Datomic not required. Mostly it would be helpful to have a doc in the devguide, next to the Heroku one

qqq05:03:23

alright, I'll wait for when you have simplified the server mode

qqq05:03:05

the other limitation of GAE is that handlers can't run for more than 30 seconds; so there can't be any long running requests (or threads); basically it has to be (1) get request, (2) figure out what to store to db (datastore in this case), (3) store, respond; and the request dies

qqq05:03:29

storing to datastore should be easy, as it's an EAV store, which maps the [keyword id] value of om/next + untangled quite well

qqq05:03:14

oh boy, querying would be "interesting", as we'd ahve to map untangled queries to datastore quries, hmmm

claudiu08:03:25

@qqq Would love to pitch in for appengine untangled 🙂 . For now started to work on enhancing the template a bit (server side rendering, html5 routing)

qqq08:03:03

@qqq: fantastic! the main choices are which appegine lib to use: our choices are: (1) https://github.com/migae/boot-gae (2) https://github.com/nickbauman/cljgae-template (3) some hacks I'm using [not recommended]

qqq08:03:17

@claudiu : ^^ last msg not meant to be @qqq

claudiu09:03:06

@qqq cool will look into those in detail as I'm setting up my intial template 🙂