untangled

NEW CHANNEL: #fulcro
tony.kay 2017-03-01T01:51:23.004795Z

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.kay 2017-03-01T04:37:00.004798Z

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.kay 2017-03-01T04:37:25.004799Z

Drop the "web framework" part of the title.

tony.kay 2017-03-01T04:41:26.004800Z

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.

qqq 2017-03-01T05:01:24.004801Z

@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

qqq 2017-03-01T05:15:43.004802Z

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

qqq 2017-03-01T05:16:12.004803Z

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

qqq 2017-03-01T05:16:23.004804Z

I can help out with the one-line gae deploy

tony.kay 2017-03-01T05:16:28.004805Z

@qqq glad to take contribs

qqq 2017-03-01T05:16:53.004806Z

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

qqq 2017-03-01T05:18:22.004807Z

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]

qqq 2017-03-01T05:18:44.004808Z

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.kay 2017-03-01T05:19:24.004809Z

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.kay 2017-03-01T05:19:52.004810Z

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

qqq 2017-03-01T05:51:55.004811Z

@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?

🙂 1
qqq 2017-03-01T05:52:18.004812Z

Oh, gae doens't support websockets

qqq 2017-03-01T05:52:27.004813Z

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

tony.kay 2017-03-01T05:53:01.004814Z

@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

qqq 2017-03-01T05:53:23.004815Z

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

tony.kay 2017-03-01T05:53:32.004816Z

k

qqq 2017-03-01T05:54:05.004817Z

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

qqq 2017-03-01T05:54:29.004818Z

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

qqq 2017-03-01T05:55:14.004819Z

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

claudiu 2017-03-01T08:23:25.004821Z

@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)

qqq 2017-03-01T08:37:03.004822Z

@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]

qqq 2017-03-01T08:40:17.004826Z

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

claudiu 2017-03-01T09:13:06.004827Z

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