Lotus, a web framework for Ruby

http://lucaguidi.com/2014/06/23/introducing-lotus.html

by krasnoukhov • 12 years ago

285 135 12 years ago

kureikain3• 12 years ago

Thank for great fw.

I'm by no mean a Ruby expert but finding Sinatra is so simple to create complex apps, and Rails is so complex atm to pick up. I'm making slowly progress in Rails and always not sure if I done thing correctly in Rails way.

Lotus seems small enough, and good enouh, balance between Sinatra and Rails for me.

Keep up the good work. Thanks.

liveoneggs• 12 years ago

http://www.padrinorb.com/ check it out

kureikain3• 12 years ago

This is so cool. Built on top of Sinatra. So I can consider it like chaplin to backbone, right? It creates an architecture on top of original framework.

diegosouza3• 12 years ago

My feeling is the same.

CarlHoerberg3• 12 years ago

sinatra is more powerful than you maybe have realize..

jamesbritt3• 12 years ago

balance between Sinatra and Rails for me.

Ramaze is that sweet-spot for me.

http://ramaze.net

kureikain3• 12 years ago

Thank you for such a great link. It is also well-maintain. last commit was 2 months ago. Its base is small enough to understand for me too. I like to understand more Ruby by reading the code. However, Rails was so big to me. Thanks again.

herge• 12 years ago

Whenever I hear lightweight and complete, I always wonder if they handle one of the hardest things to do cleanly in web-apps: user authentication and access control of resources. Does Lotus support this out of the box?

mmanfrin• 12 years ago

A quick look at the API[1] showed a couple mentions of Sessions in the example structure. Not sure if it is handled out of the box, but I get the impression it is not difficult to implement. But that is just authentication, no idea about access control.

[1] http://rdoc.info/gems/lotusrb

diegosouza3• 12 years ago

It doesn't. It's only the base, but a well constructed base.

fuadksd3• 12 years ago

It doesn't, nor is supposed to. It is composed of small parts with as little responsibility as possible. The idea of Lotus is to not force you to use any tool or favor any kind of approach to such things, but instead give you enough "frame work" to compose with other tools that are responsible for such tasks like authorization, authentication, persistence, or really any kind of stuff you need to do.

chrisdevereux• 12 years ago

Slightly OT, but as a mobile guy who occasionally toys with server-side programming, authentication is always where I get stuck. I'd like to see some examples of how to implement authentication and sessions cleanly without too much framework magic. Any pointers?

p8952• 12 years ago

Rolling your own? This is as simple as it gets: http://128bitstudios.com/2011/11/21/authentication-with-sina...

If you want to make it even easier, use OmniAuth: http://recipes.sinatrarb.com/p/middleware/twitter_authentica...

rhgraysonii• 12 years ago

I'm intrigued. Just signed up for the mailing list. Do you have any links to applications built in Lotus?

krasnoukhov3• 12 years ago

Here is a simple gist from Lotus author: https://gist.github.com/jodosha/9830002

And also there is a WIP room reservation app: https://github.com/sidonath/room-reservation

krasnoukhov3• 12 years ago

Just found another example app: https://github.com/joneslee85/lotus-blog

fuadksd3• 12 years ago

There aren't many applications using the solution as a whole - as it was just made public recenltly, but you can check some example applications used for tests in the lotus repo: https://github.com/lotus/lotus/tree/master/test/fixtures/

deedubaya• 12 years ago

This is an interesting attempt. It has Sinatra like simplicity, providing the modular architecture that was promised with the Merb + Rails merger.

At the very least, this will spark some interesting conversations and ideas.

Eleopteryx6• 12 years ago

This is depressingly similar to what I was aiming for when I recently began work on: https://github.com/lean-framework/lean (I feel like this happens to me a lot.)

Rails controllers are hard to test because actions aren't designed to be testable objects.

ActiveRecord models become monolithic because there's no separation of instantiation, validation, persistence, or retrieval.

I originally experimented with building a Rails app that forgoes ActiveRecord to a large extent; using plain Ruby classes + Virtus gem to separate the aforementioned concerns depending on context.

I was pretty satisfied with the number of design headaches I was able to avoid, which is when I started to create a framework around the aforementioned paradigms.

Not sure if I just lost my motivation or not, but I'm glad I'm not alone.

desireco42• 12 years ago

Maybe you just found your kindred spirit and can join forces and produce something awesome for all of us

Eleopteryx6• 12 years ago

I'd be OK with that.

yid• 12 years ago

This is depressingly similar

In graduate school, many a moon ago, my advisor would say that this is validation of the idea, so one should be happy to be on the right track.

Eleopteryx6• 12 years ago

Thanks for the de-demotivation.

ealdent• 12 years ago

I seem to recall, a while back the creator of RVM suffered a similarly disheartening setback when rbenv came out. RVM is still going strong. The community has not decided on lightweight frameworks. The choices you make won't be the same as lotus. You will no doubt attract a group of like-minded people who will be grateful for your contributions.

jaredcwhite• 12 years ago

I'm all for new frameworks that emphasize different ideas and philosophies. If nobody ever tried experimenting with a new approach, we wouldn't have Rails in the first place. So kudos to Luca and his fine work in developing Lotus. I like much of what I see.

That being said, I feel like YARWF (Yet Another Ruby Web Framework) is not the most pressing matter in the web space today, and I take exception to the notion that this is a complete web framework. It's not. A complete web framework has client-side components that facilitate two-way communication to/from the server, data binding, HTML5 history state-based page/view swapping, etc. In other words, the type of stuff being addressed by Angular, etc. At this point I wouldn't even characterize Rails itself as a "complete web framework"...it's proven itself to be incomplete and needs something more to be added to it for this kind of stuff.

What's the solution? Well, most people in the Ruby world do the typical route of a Ruby + Rails/whatever backend and a JS-based (or CoffeeScript-based) frontend. But I don't like it. I want one language that works on both sides and in fact allows OOP code sharing between the two.

That's why I'm so bullish on Opal (http://opalrb.org) -- Ruby-to-JS compiler. It may not be perfect, but it's usable and it's here now. What we need is a framework built on top of Opal that is to the client what Rails, or Lotus, is to the server. Then I think we can safely say that we have a complete web framework solution for Ruby. Until then...not quite.

diegosouza3• 12 years ago

You say "A complete web framework has client-side components", but you don't consider there are action based frameworks and component based frameworks. They follow different approaches. Lotus is action based.

bliker• 12 years ago

You are forgetting that not all people are building thick-client applications.

gnufied• 12 years ago

I want one language that works on both sides and in fact allows OOP code sharing between the two.

I think, having one language in both frontend and backend does not work in long run, regardless of your preferred language of choice.

we love ruby and yet where I work - we actively maintain Ruby, Python, Javascript and Java applications. Besides, I find it too hard to write OOP code which is reusable within same problem domain, writing OOP code that crosses the concerns between backend and frontend sounds like inviting lot of problems and lot of useless discussion on - which code goes where.

EDIT: I didn't mean business agnostic code can't be shared between frontend and backend btw. Date parsing, uri parsing etc are examples of such libraries. But overall aiming to write business code that can be shared between frontend and backend is problematic.

zem• 12 years ago

there are some great frameworks that do do one language everywhere (my top choices would be om and hoplon from the clojurescript camp, and opa from the custom language camp). there is something to be said for being able to seamlessly pass data around between the frontend and backend, and letting the language and framework handle the low-level details for you.

alttab2• 12 years ago

This can happen with knockout and other libraries when you end up dumping data into an object to send over simply to render it view side. You end up with a lot of wires between your controller and the view template rendered on the client side.

thecoffman• 12 years ago

A complete web framework has client-side components that facilitate two-way communication to/from the server, data binding, HTML5 history state-based page/view swapping, etc. In other words, the type of stuff being addressed by Angular, etc.

No. I can't possibly disagree with this any more strongly.

I'm probably on the wrong side of history here, but Javascript absolutely should _not_ be a requirement for using a website. If your website doesn't work with NoScript turned on, I won't utilize it. Full stop.

In my mind Javascript should be used for progressive enhancement for those users that opt to enable it (or I suppose more correctly: choose not to disable it). Building a thick client web app is the fastest route to ensuring I won't use it.

blktiger• 12 years ago

You are welcome to hold that opinion. Just keep in mind that the majority of users don't even know what javascript is or how to disable it. Depending on the audience, the fact that you don't want to enable javascript may or may not be a concern to the developers.

Igglyboo• 12 years ago

If your website doesn't work with NoScript turned on, I won't utilize it.

You're definitely in the minority then, most users don't even know what javascript is let alone NoScript. I find it ridiculous that people are arguing against javascript, we're using a computer and not allowing it to run code.

king_magic• 12 years ago

I respect your opinion, but I will happily disregard it when it comes to building web apps. If that means I someday lose you as a customer, so be it.

twerquie• 12 years ago

You are fighting a losing battle.

rhizome2• 12 years ago

I suspect that many sites simply do not have staff and/or resources capable of producing NoScript-friendly (degradable) work.

rakoo• 12 years ago

I used to think like you, but I've since understood since that this is the wrong battle. You have 2 things that are more and more diverging yet use the same platform for distribution:

- websites as-you-know-them, which goal is to provide _information_

- webapps, which goal is to provide _services_

Your point of view is completely valid for the first kind: when you want the information, you don't want the frills that go around it. You want clear pointers to it in the form of clean URLs. You want it to be accessible on your smartphone that doesn't run javascript because it's heavy and has wildly different inputs.

But the second kind is completely different. When you (as in the general you) are using GMail, you actually want to use an application to manage your mail, possibly send and receive them. Whether it's in your chrome browser or native in your OS matters only as far as how easy it is to install, and on that point the web has won. But it's just a happy accident of how things have evolved.

You are not against javascript per se, you are against web apps in general. Which is totally understandable, because there are better ways to provide services on a computer than using a shiny HTML+CSS+Javascript interpreter that fetches programs on-the-fly and can't even do half of what a real OS can do.

pbreit2• 12 years ago

I couldn't care less about losing you as a visitor to my site. It's 2014. JavaScript is required for using the web.

wirrbel• 12 years ago

I think the turning point is already ahead of us where the thin client server-heavy webservices will be considered a "smell" or at least the uncanonical way of developing web apps.

It pays off to do a lot in the client (good libraries provided). You have a high frequency of development iterations, direct response during development and you are working closely to the "medium" of presentation.

I have had a project that started out as a flask web app and all of the sudden, I realized that moving things to the JavaScript world in the client (I was using ClojureScript there) was actually safer, faster and better than keeping it on the server. In the end the server Did validation and database access in the sense of a Web API. It really was a clean solution

pyrrhotech• 12 years ago

What is your aversion to javascript? As a client-side scripting language, it enables us to deliver, much, much richer UX to the end user. It should not be put aside as just for 'progressive enhancement'. That's ridiculous. This comment wins my nomination for most backward of the year on HN.

hmsimha• 12 years ago

Look, I'm all for progressive-enhancement driven development where it makes sense. But there are (many, many) websites where it doesn't make sense nowadays.

If your website doesn't work with NoScript turned on, I won't utilize it. Full stop.

I take it you don't use Youtube? Even for the parts of the web that do work without javascript, enabling js usually offers an enormous improvement in usability. I don't want to reload the page every time I upvote someone on Hacker News for example.

While I don't believe there's a canonical definition of what constitutes a complete web framework, I do agree with your main point though; things like data two-way communication and data-binding shouldn't be a prerequisite for qualification as such. That would imply that 'complete web frameworks' didn't exist before 2011 or so.

Rapzid• 12 years ago

Some might say you were on the wrong side of history.. If they even knew where the line got to. I doubt anybody has seen it in the past 5 years, so who is to say?

Skoofoo• 12 years ago

Vienna is a Ruby web front-end framework that looks promising. https://github.com/opal/vienna

Iftheshoefits• 12 years ago

A complete web framework has client-side components that facilitate two-way communication to/from the server, data binding, HTML5 history state-based page/view swapping, etc. In other words, the type of stuff being addressed by Angular, etc. <

What you describe sounds very much like Plato's shadows (search for "Allegory of the Cave") when compared to a native application.

Web browsers aren't operating systems. They weren't and still aren't designed to be general application execution environments.

chrisweekly2• 12 years ago

"We have infinite combinations. Small components have enormous advantadges in terms of reusability."

Typo: advantages.

Just a nit, but it does stand out since it's in the first bolded sentence on the page.

chrisweekly2• 12 years ago

"We have infinite combinations. Small components have enormous advantadges in terms of reusability."

Typo: "advantages". Nitpicking, I know, but it's in the first bolded sentence on the page and it detracts from your messaging.

Cool project, good luck! :)

jamesbritt3• 12 years ago

Additional nitpick: "fewer" instead of "less", as in

"... you employ fewer DSLs and ..."

mrinterweb2• 12 years ago

By what I've seen I like the spirit of Lotus, but I sense a movement away from complete web frameworks to pure API back-ends with the emergence of great single page JS frameworks like Ember. One ruby one that I like is https://intridea.github.io/grape/. One interesting node API framework I mean to try is http://loopback.io/.

joevandyk• 12 years ago

You could easily use Lotus as an API server.

fuadksd3• 12 years ago

That's a trend indeed (and personally I like it pretty much).

But lotus has a view component that allows you to do stuff """just like rails""" (many quotes intended). That's the beauty of it: it's modular and not opinionated, so you can pick an mix the tools you want to compose in order to suffice your needs.

awj• 12 years ago

Yeah, lotus looks like it could do a good job at letting you share/extend models and other bits of code between a Rails-like html server and a pure api server. Maybe those two things are the same server, different modules in the same server, or different servers sharing libraries. Choice is up to you since lotus looks like it can cleanly do both.

shime3• 12 years ago

Yes, I also think that the future of backend development is micro services communicating over defined HTTP API endpoints or other message protocols.

If you look closely, rendering presentation layer on the server side and then sending it to the client is a hack and we've been doing it for a long time. It's time for changes.

h1karu• 12 years ago

Single page web apps are broken for a lot of the most important purposes that the worlds largest and most important web-apps need to fulfill. For example how could Wikipedia function as a single page app since it wouldn't be consumable by screen readers and robots of various shapes and sizes ? That's just one example, but there are many. What about the semantic web ? microformats anyone ?

Google isn't the only search engine out there so the fact that you can use a crutch to let google crawl your site doesn't fix the problem.

https://en.wikipedia.org/wiki/Semantic_Web http://www.w3.org/standards/semanticweb/

Smudge• 12 years ago

If you look closely, rendering presentation layer on the server side and then sending it to the client is a hack and we've been doing it for a long time. It's time for changes.

From the view/presentation layer's perspective, it shouldn't matter where the rendering happens, and as a programmer working on these systems I'm tired of baking assumptions about the data layer into the view layer.

I actually think there's a best-of-both-worlds solution that we'll converge on at some point, which is this:

We have the option of rendering in both locations with the same code.

This allows the initial render to be offloaded to the server (so that the app's initial state is totally established and can be sent along with the app itself in a single HTTP request), and then subsequent rendering updates could happen mostly client-side (fetching only the raw data from the server where necessary).

This allows the JS-everywhere crowd to build their entire app as if all logic is running in-browser (with only a basic API on the server), but it appeases the more old-fashioned developers who want to be able to construct mappings between URLs and actual HTML documents (that don't have to be spun up and re-constructed using client-side scripting). There's obviously a huge debate here as to whether or not the latter is worth it, but I'd say it would be nice if only so that I don't need to have a flash of unloaded content or a "loading" indicator before the app is ready to be used.

I also don't like having to use PhantomJS to scrape data from a website that could very easily consist of HTML documents instead of a blob of JS, but that's probably not enough to affect most people's opinions.

jeltz• 12 years ago

To me the examples look too wordy compared to sinatra or padrino. Like the lack of auto loading though, the autoloading is my opinion a huge mistake in rails and padrino.

DogeDogeDoge• 12 years ago

How many of this type of frameworks we had. Padrino was there to fix something but achieved nothing. It is better to focus on rails and fixing rails rather than start a framework for everything.

Few doge years ago sinatra was faster than rails, today... not so obvious and still offering much smaller set of functionality.

vidarh4• 12 years ago

It is better to focus on rails and fixing rails

For many of us "fixing Rails" is easiest achieved by starting from scratch.

and still offering much smaller set of functionality.

... and that is why I prefer Sinatra to Rails.

dragonwriter2• 12 years ago

For many of us "fixing Rails" is easiest achieved by starting from scratch.

See, e.g., the road to Rails 3 through Merb.

moger777• 12 years ago

Theres a bit of politics that get in the way of "fixing rails". Mainly, many things that others consider anti patterns, DHH and other maintainers are fine with.

CarlHoerberg3• 12 years ago

sinatra/base, rack-urlmap and sequel, why would you want more fluff?

krasnoukhov3• 12 years ago

It looks like you're missing the point. As an example, I've built the adapter for DynamoDB[1] so you can throw sequel out in matter of minutes even for existing app, and most likely without any code change.

[1] https://github.com/krasnoukhov/lotus-dynamodb

CarlHoerberg3• 12 years ago

No, if I choose Sequel (http://sequel.jeremyevans.net) I want to use all the power it gives me, not some lowest common denominator.. Also not all projects needs models, you know, there's other data access patterns..

vidarh4• 12 years ago

The presence of Lotus::Model was a red flag to me, until I realised that Lotus doesn't seem to depend on it being used? I don't want my web framework to dictate my model API.

Lotus::Model may be great, and I like that it's actually trying to implement the DataMapper pattern, but there are projects where all the model code was written for the backend and we only later decided to expose it as a web API for example, and switching to another model layer would be out of the question.

You might want to emphasise more strongly that these components can (assuming I'm right) be mixed and matched with other components like Sequel if you prefer, since the naming sort-of hints that it's all tied together.

emiller829• 12 years ago

This is a promising start. I've felt for a while now that we need some strong alternatives to Rails for the folks who feel like the Rails Way and the Ruby Way don't always get along.

It still feels a bit DSL-centric from the examples I've seen thus far, and haven't dug into things to see what the generated Ruby looks like -- but if it's anything close to simple, this is something that has a chance to become an important part of the Ruby ecosystem.

If nothing else, it's great to see things like this because they provide concrete example code for discussions that (IMHO) need to happen.

jamesbritt3• 12 years ago

I've felt for a while now that we need some strong alternatives to Rails for the folks who feel like the Rails Way and the Ruby Way don't always get along.

This is why I prefer to use Ramaze. It feels more natural if you're already used to coding in Ruby. It also supports the evolution of development from lightweight to complex sites without having to switch frameworks.

http://ramaze.net

jrochkind12• 12 years ago

For a while, I thought Sinatra was taking that role? It might be interesting to think about what people are looking for that's neither Sinatra nor Rails, or why Sinatra didn't live up to what people were hoping (if people think that).

Sometimes I think some of this is just utopian grass-is-greener thinking. While there are _many_ things I'd do differently in Rails if I had the choice (some but certainly not all of which the Rails core team probably agrees with, if they had the chance to start over)...

...I think some of the "the thing we need is something _lighter weight_ than Rails" thinking is basically wishful thinking. When you start with something lighter weight, you (being me) generally find you need more than it offers, and then you've got to go finding your own things to do those things, and when these extra third party things end up not as high quality as you'd like, or end up abandoned by their developers, or you end up spending many hours re-inventing a wheel you're sure someone else has already invented.... either the 'lighter thing' ends up gaining weight, or you end up wishing it had.

Doesn't mean I agree with all of Rails choices about what to include, or how to architect it. But I think people under-estimate how challenging it is to hit the sweet spots, as if Rails core team just lacked the will or intelligence or proper understanding or something, none of which I think they lack. Still, certainly alternatives are great, testing grounds for other possible ways of doing things are great, the more different things we see, the better all of our architecting and coding gets, that's the only way to learn.

pandatigox• 12 years ago

Sinatra, in my opinion, gets pretty hacked together after the initial `def get '/'; puts "Hello World"; end`

Personally, I think Camping is the perfect fit for Ruby frameworks

pmontra2• 12 years ago

For any project worth talking about Sinatra is too skinny. Basically you have to hack your routing in about the same way you do with Node's Express, enumerating the bindings between routes and methods. Obviously there are clever ways to do it but you end up reimplementing the resourceful routes of Rails.

Another problem is that you really want to use ActiveRecord to access the database. Anything else it too painful. So you end up creating AR models and you have to manually include them.

Finally there are views. I won't even enter into that.

Soon you end up with a worse engineered Rails. I've been using Sinatra only for serving API requests for small projects. I won't touch it for anything else.

regularfry2• 12 years ago

Rails is a pile of conventions. What I want isn't something more lightweight, it's something heavyweight with different conventions.

cies• 12 years ago

Feels like Merb all over again!

Data Mapper, significantly less code, humble core-contributor.

Great work!

Eleopteryx6• 12 years ago

I really liked Merb, and stuck by it for some time. Rails 3 was supposed to be Merb 2. It wasn't really, but Merb was still lost to the "merge".

tinco3• 12 years ago

Weird, I get the idea of defining a new web framework API, but why would you build everything from scratch? There's loads of very good open source code out there.

Why not fork DataMapper for Lotus::Model for example? Now you have some dodgy hand rolled library that's probably not seen enough eyes to be really production proof.

gkop• 12 years ago

Lotus::Model apparently depends on https://github.com/jeremyevans/sequel , which has been widely used in production similarly to DataMapper.

tinco3• 12 years ago

It seems you are right, my apologies, I clearly hadn't read deep enough. Still, Sequel is just an SQL abstraction. DataMapper is exactly what Lotus::Model is, a full model abstraction over databases, regardless of the querying language.

Some years ago I even implemented an XQuery querying backend for DataMapper, it was not much work at all, at a time where AR still had SQL code all through the base and Sequel was just in low profile development.

atmosx• 12 years ago

Sequel is way more actively supported/developed compared to datamapper. Last release of DM was in 13/10/2011...

JonnieCache• 12 years ago

Sequel, (and Sequel::Model) is an absolute peach. The best ORM I've ever used.

EDIT: Lotus::Model barely seems to use Sequel. Maybe I missed it...

vidarh4• 12 years ago

Note that DataMapper does not implement the DataMapper pattern but the ActiveRecord pattern. Lotus::Model appear to aim to implement the DataMapper pattern. They're fundamentally different.

programminggeek• 12 years ago

I think it's great to see someone make a run at a more decoupled ruby web app approach. I hope it succeeds.

In my experience working on Obvious (http://obvious.retromocha.com) it is hard to get Ruby developers behind decoupled architectures because the large majority aren't Ruby devs, they are Rails devs and Rails happens to be in Ruby.

Also, the larger group of developers doesn't like the idea of an app being a giant collection of very small objects. It's like there is a gravity to the notion of objects where we think of an object as something akin to a car, not the thousands of parts that make up a car.

Last, I think the idea of MVC doesn't place the appropriate number of objects for the different roles in normal request processing. At a reasonable point of complexity really end up with routes, controllers, entities, data access objects or repositories/adaptors, presenters, views, templates, helpers, utilities/libs, and probably some other bits of random code in there somehow. That doesn't fit the 3 role view of the world that is MVC.

Lotus does a better job than most of addressing such things, but I think the MVC approach in general falls flat.

That lack of appropriate roles means that as programmers we invent a lot of names, patterns, roles, etc. to fit what our code actually ends up doing. That's why you see a lot of service patterns, presenter patterns, etc. being attached to Rails. Everybody is duct taping their approach to the notion of MVC, but very few are saying "what if we didn't see request processing as only having 3 roles?"

MVC is better and cleaner than writing a page as one giant PHP file maybe, but I've seen it fall down so many times that I no longer trust it as a useful pattern or abstraction for expressing request processing and HTML string manipulation in code.

In fact, if we were building command line apps and writing to files, I don't think we would use MVC at all. But, since we're writing strings of HTML, it's totally different right?

al2o3cr• 12 years ago

I'm pretty sure they make a pill or something for that scorching case of hasheritis. ;)

One problem I have with "decoupled" architectures is that the only way you can sensibly interop with everything from RDBMS to flat JSON files is if you treat the RDBMS as a flat file. For instance, the sample Twitter clone treats every available DB as a plain key-value store.

regularfry2• 12 years ago

One problem I have with "decoupled" architectures is that the only way you can sensibly interop with everything from RDBMS to flat JSON files is if you treat the RDBMS as a flat file.

The Repository pattern is what you're looking for.

hyperliner• 12 years ago

Is it weird / bad karma to call this "Lotus"?

mrinterweb2• 12 years ago

You could make an example application called "Notes" with Lotus.

rbanffy• 12 years ago

Or a spreadsheet and call it "123"...

Or even worse - a webmail app called "cc:Mail".

drivers99• 12 years ago

Considering that IBM owns the trademark for "Lotus" for software products, I suspect there will an issue with that at some point.

mdavidn• 12 years ago

Lotus::View is the first library for Ruby that marks a separation between view objects and templates.

This is a great idea, but Lotus::View isn't the first. See Mustache.rb, for example.

https://github.com/defunkt/mustache

SeanLuke2• 12 years ago

This is a textbook example trademark infringement. IBM will not be humored.

matdes2• 12 years ago

uhhhhhh, I don't know if that's true.

Lotus was never a ruby web application framework. Guess Apple's going to have to change the name of Swift because of that other programming language, amirite?

SeanLuke2• 12 years ago

Lotus was never a ruby web application framework.

A trademark's domain is nowhere near that specific. Recall that Apple was sued by Apple Records because it made devices capable of being used "in the record business".

Guess Apple's going to have to change the name of Swift because of that other programming language, amirite?

Interesting that you say this. Apple certainly has a history of trademarking its languages. Apple has trademarks on Objective-C and on AppleScript. Its trademark on Dylan was abandoned and its trademark on Hypertalk was cancelled. I'm guessing that Apple hasn't trademarked Swift because it can't: there are two many other items already named Swift in the area. And the Swift scripting language is hardly a threat to them: it's an NSF-funded research effort.

jbeja• 12 years ago

Isn't this old, i know i have heard of it several years ago.

lobster_johnson3• 12 years ago

Looks nice. I particularly like the ORM, which seems well-designed compared to ActiveRecord.

That said, I have a distinct feeling this is too little, too late. I and my teams have long migrated away from frameworks, to microservices, or what some people call SOA, and we are not looking back. I strongly encourage this design over the old monolithic Rails approach.

These are mostly small, highly specialized Sinatra backends that speak data only through REST APIs. For such backends, you don't need views, and you hardly need models; when "deconstructing" your data model into multiple backends, the data model for each microservice often becomes absurdly simple. Mostly you need a simple way to express REST endpoints. Sinatra is very simple and doesn't support any abstraction, but that's mostly a good thing. And you can split your API across multiple files easily. The backends are getting so simple that it's starting to look very tempting to migrate to Go, where we could get real performance and concurrency.

On the front end, I would still use Sinatra if it were a classic app -- you can cobble together a "railsy" app with Sinatra by picking your template system, database layer and so on -- but mostly these days we build Node.js single-page apps that are sewn together with NPM and Browserify. Web app development has never been as simple and elegant as it is when done this way.

jshen2• 12 years ago

Can you give done examples of the types of things these micro services do?

kidmenot• 12 years ago

+1, I would love to take a look at an example or two, as this sounds very interesting.

stevekemp• 12 years ago

Not the poster, but I've written a few small sinatra-endpoints in my time.

For example I wrote a self-hosted comment-system, which is like a very basic disqus service. The back-end is a simple sinatra service that just allows "GET /comments" and "POST comments". (http://github.com/skx/e-comments/)

Last week I wrote a webhook-consumer, again using Sinatra. It receives a POST from github, parses the received JSON, and adds some details of the body into a queue for later processing.

Both services allow simple deployment and total may 50 lines of code each.

lobster_johnson3• 12 years ago

Sure. I have been thinking about writing up a blog post about our work since it may be of use to others. A quick summary of some of our current microservices:

- Single sign-on. We have a service that abstracts users into identities that map to one or more actual logins. It facilitates the OAuth interaction with providers. To add login in any app, you just redirect the browser to the microservice's /auth/:provider API; it redirects through FB or whatever.

- For sites that don't want to rely on providers like FB, we also have a simple OAuth provider that has a basic user database with salted passwords, email/password management, etc.

- Data store. We have a structured, hierarchical document-oriented data store that is a thin layer on top of PostgreSQL. Most apps don't have their own database, but use this data store.

- Security. We have a common, path-based security model across apps that can be validated through calls into a central security microservice; it's mostly a registry of what apps delegate responsibility, and when you ask the security service about whether, say, you're allowed to modify the object at path acmecorp.blogapp.posts.1, it asks every app that is registered to be the authority for that path. For example, acmecorp.blogapp might use a role-based security system, but a different path exampleinc.cmsapp might use LDAP.

- Voting. For Reddit-style voting and kudos we have a small microservice.

- Search. We wrap our data store in an indexing system that uses ElasticSearch.

- Organizational management. We have a microservice that handles members, groups and their roles. It plugs into the security system so that we can delegate access to very precise parts of the system. For example, any user can see comments, only the author can edit a comment, and editors can update anything.

- Email/texting. We have a microservice that abstracts text and email, currently supporting things like Mailgun and Twilio. It allows us to swap out the implementation without the app knowing.

- GIS/map stuff. We have a separate microservices for geocoding and storing GIS features.

- Image/audio/video processing. We have a wrapper around ffmpeg and other tools that processes transcoding requests.

An important piece of the system is the extensive use of pub/sub via RabbitMQ exchanges to asynchronously publish and listen to events. For example, any microservice can listen to changes to any part of the data store (based on path or event). For example, our search microservice automatically populates ElasticSearch with content from the data store.

Lastly, every app has a microservice as its own backend; for example, if the app is a blog system, we have a frontend (eg., a Node.js desktop/mobile web UI), and a separate backend tailored to that frontend; the frontend treats the backend like any other microservice.

shime3• 12 years ago

This sounds very interesting. Please make a blog post about this if time permits. We seriously lack good resources about micro services when it comes to Ruby.

fredwu• 12 years ago

The ORM part, largely due to the repository pattern, is very similar to my earlier attempt - Datamappify - https://github.com/fredwu/datamappify

Given time, effort and popularity, I could see Lotus::Model to become the de facto alternative to ActiveRecord, overtaking the ROM (Ruby Object Mapper, previously known as DataMapper) project. :)

izietto3• 12 years ago

At the moment, if I should switch from Rails to another Ruby framework, the killer feature would be a well integrated built-in streaming support (something like Lotus::Live in this case), which nowadays is a must for a web framework; otherwise the stability of Rails and the big community around it (people, gems) would win against this project, as against the many other current Ruby frameworks.

Anyway I wish good luck for this project, which was created by a person of the same country of mine (Italy), of the same city (Rome) and which I met at the only Ruby meeting ever done in Rome I suppose, a couple of years ago.

shime3• 12 years ago

stop complaining and start a Rome Ruby meetup group. I did that couple of months ago with Ruby Zagreb meetup group. Europe, and especially eastern Europe needs more meetup groups!

izietto3• 12 years ago

I wasn't complaining about it, I just reminded when I met him. I don't feel the missing of meetups, I prefer internet communities (mailing lists, GitHub, HN...)

pmontra2• 12 years ago

Rails has http://api.rubyonrails.org/classes/ActionController/Streamin... which I never used. It seems that Lotus::Live isn't ready yet. I can't find any docs for it so I don't know how they compare. Could you point me to an URL. Thanks.

izietto3• 12 years ago

Yes, but ActionController::Streaming is not made for long pooling; what I mean is 1) web sockets and/or server side events support and 2) Raisl streaming helpers (models watching, client events, etc.); essentially, the good parts of node.js frameworks.

Lotus::Live doesn't exist, it is a name example for the feature of which I feel the missing.

ksec• 12 years ago

It is rather interesting that most parts of Lotus has been posted on HN every months, and yet dont even get more then 10 comment and a few points, not to mention it was never on the HN frontpage.

Now all of a sudden it has 241 point. 134 comment.

Lotus, a web framework for Ruby

Related Stories