search

ruby-hyperloop / ruby-hyperloop.io

The project has moved to Hyperstack!! - Ruby Hyperloop Website and Documentation
https://hyperstack.org/
22 stars 18 forks source link

Creatively expanding Hyperloop base... #98

Open ylluminate opened 6 years ago

ylluminate commented 6 years ago

@catmando not sure if you saw this discussion previously in Gitter, but I have been thinking that a portable Hyperloop that can run atop Amber or even Lucky frameworks for Crystal might be very attractive for the communities. It could be argued that having Hyperloop / Opal on these provides a more isomorphic platform even though it's not one-to-one per se. Nonetheless, it would very much expand desirability for those hunting speed while keeping a primarily Ruby environment.

catmando commented 6 years ago

I certainly agree. It think it would be very very powerful if we had a crystal -> JS transpiler (like Opal)

Meanwhile i guess it does make sense as interim step to at least integrate hyperloop (FE) with a hyperloop crystal backend, compatible with either AMber or Lucky or both.

ylluminate commented 6 years ago

What is the "FE" nomenclature? I am assuming it's some kind of a "bare metal" (FE reminds me of "iron") interface that would allow interop with other crystal backends such that perhaps there is a single interface provides the necessary translation for them...?

Just brainstorming, any thoughts on what would be the best approach to start such an effort?

catmando commented 6 years ago

FE = frontend (client side) BE = backend (server side) Full stack framework (i.e. hyperloop, meteor, volt) = FE + BE integrated

So your proposal as I understand is to somewhat to a version of hyperloop that is 100% compatible for the FE part of the code (i.e. the client etc) but would use crystal on the BE (server)

The problems to solve are

  1. what kind of ORM does Amber/Lucky have? Then you have to adapt the current Hyperloop server side code to use that ORM. Could be fairly easy depending on what kind of hooks the ORM supports. Hyperloop just needs a few things to work.
  2. figuring out how ServerOps are going to get called from the client.
  3. Hyperloop has a pretty small controller you would have to port to your crystal framework
ylluminate commented 6 years ago

LOL, gotcha. I guess we all have too many acronyms floating around our heads.

I'm no authority on either framework; we're just looking at using Amber primarily as a Rails replacement for a couple of projects right now due to the marked speed and memory consumption improvements and it would sure be nice to have hyperloop to run atop this. I think we've all been hoping to see things improve in the ruby space with Truffle and such, but Crystal takes things so much further performance wise right now (even though it's still not entirely mature), that it's hard to ignore.

Re: each framework:

I'd personally say that Amber would probably be the primary target for the moment.

barriehadfield commented 6 years ago

@ylluminate your joining of the dots is much appreciated.

paulcsmith commented 6 years ago

Hi @catmando! I'm the creator of Lucky. I like the idea of Hyperloop and I've been interested in Opal before. I'd prefer isomorphism over using Elm. I also like the idea of mixing and matching where most pages are generated on the backend in Lucky, but something like Hyperloop could be used for just a few components.

You can see that Lucky actually has Hyperloop like components generated with Crystal methods: http://luckyframework.org/guides/rendering-html/#adding-a-page so I think it could be a good fit.

What kind of hooks would LuckyRecord need to work with Hyperloop on the front end?

fkchang commented 6 years ago

@paulcsmith looking at the crystal guides page, it looks like the rendering examples could be in that subset that is the same in both ruby and crystal -- in my mental thought experiments of how an opal/crystal full stack framework would work, in the ideal case, there could be some isomorphic opal/crystal code if coded to some guidelines (possibly a tool to ensure they run on both) -- so I think there is potentially something quite cool that could happen

fkchang commented 6 years ago

@paulcsmith hey, so I'm wondering what the quickest way to hook opal into lucky would be. I see from http://luckyframework.org/guides/asset-handling/ you're using brunch. I've never used brunch, but I guess the brunch equivalent of setting up webpack to compile opal files. Where I'd like to go with that is be able to have hyper-react load initially with brunch, have opal-hot-reloader hot reload transpiled Opal and css (though I don't know what I'd have to do to support hot reloading of the css - but if it's similar to how Rails does it, I can watch the compiled .css files), but also have a directory of code that can be run on both front end and backend. With Ruby based systems, we can use sprockets to both compile the opal code as well as allow the sharing of front and backend code via shared directories -- I'd be curious as to how to do the same with Lucky/Brunch -- possibly via config. Lastly, having some sort of backend components that could prerender the hyper-react components, perhaps a class that on the frontend inherits from HyperComponent and on the backend, inherits from something else, so the code looks the same -- though that might be too much to ask for, or too complicated (won't support JS based components on server side render like we can do in ruby-hyperloop) -- but food for thought.

I'm thinking if we could throw together a quick configuration, it could make for an interesting test bed. @barriehadfield might have ideas having written https://github.com/ruby-hyperloop/hyperloop-rack-webpack-stack -- had addressed similar issues

janbiedermann commented 6 years ago

Re 2. figuring out how ServerOps are going to get called from the client:

For the time of transitioning, this could be done in a server side JS engine, bridging to the crystal backend. This way you can run the opal code on the server side, calling via the bridge in to the crystal backend. For example.