I was wondering if anybody has used the sugar framework for a real project? I am thinking about using it for my next api project and was hoping for some tips.
Why build this when Dynamo, Weber, and Phoenix exist with growing communities? While both projects are great in their own right, Sugar aims to be another contender, sparking more development on all three projects (and/or others that may follow) and giving developers another option when deciding what framework fits their needs best. Sugar may even strive to shake things up just as ChicagoBoss has done.
6 Likes
Why use it over say, Phoenix?
(I added some info to your post btw)
Phoenix looks nice. I haven’t spent to much time with it. When I worked in ruby I liked to use Sinatra and in python I prefer flask over django. Sugar seems to follow the path of sinatra and flask, so I figured I would play with it first. I wanted to see if anyone else had experience with sugar. I plan to write a test project in both, so I can get a first hand feel for them both.
2 Likes
Phoenix is actually much more like sinatra or flask than rails. It is made up of a few modules based on a pattern called Plugs. The way Plug works is that it creates a datastructure representing the connection, and then it passes that conn through a sequence of functions. Each of those functions are called plugs, because they abide by the Plug interface: they both receive and return a conn.
Phoenix routers are a plug, phoenix controllers are plugs, phoenix endpoints are plugs. It’s all exceptionally simple.
In order to facilitate new users, phoenix.new by default generates a full stack of stuff, but you can use flags to pair it down to just the basics.
Sugar is also based on plug, so both phoenix and sugar operate at the same level of abstraction.
Sugar also strikes me as a bit out of date. It mentions Dynamo in the readme for example, and Dynamo has been dead for over 3 years…
6 Likes
Hello. Sugar Framework contributor here.
I mainly used Sugar when I was creating dead simple APIs and websites and when Phoenix was too heavy to configure/use.
6 Likes
Thanks for the explanation. I am definitely going to spend time with both.
1 Like
Did anyone spend time with the sugar framework?
I would be interested in experiences had with it.
I am curious not due to any dissatisfaction with phoenix but because I think that a vibrant ecosystem has more than one web framework.
Well phoenix is not really a web framework, it is just a set of plugs that you can optionally use or rip out as you want, in addition to an awesome pubsub and websocket interfaces, also optional. 
But yes, more plugs is not bad.
2 Likes
What I would be far more interested in is alternatives to Plug honestly. Elli for example is a fantastic erlang webserver but Plug’s semantics don’t map on to it very well. There have been a few attempts to get Plug to work with Elli and I haven’t seen any of them actually pan out.
Phoenix is basically just a “roll your own framework with these handy plugs” into which people integrate one of the dozens (hundreds?) of plugs available on hex.
3 Likes
I am experimenting with an alternative to plug called raxx. Very much work in progress at the moment but I hope to share more about motivation and progress in the new year
2 Likes
Looks like Elli development moved here: https://github.com/elli-lib/elli. I talked to Eric recently and we discussed plugs, Elixir/LFE integrations. So if have ideas or just something please let us know.
Why fork the repo? I think if you just change ownership to the elli-lib organisation then people will be redirected from the old page
I don’t know, Eric forked it first. We can ask knutin to add the link to the readme though.
As, sorry I though knutin must have been one of the people who moved it.
Also I tried a raxx integration for elli, it’s still there in the adapters folder. Might be interesting to see how the plans/idea for elli map with some of the things I have been experimenting with, such as considering remote services and local controllers to be pretty much the same thing
I’ve never used Sugar but I did use Flask and it was a mistake. Micro-frameworks have a low barrier to entry but “convention over configuration” frameworks have a lot more embedded knowledge and best practices. If you read the Programming Phoenix book you’ll that sort of wisdom referenced everywhere.
Unless you’re very experienced at creating web apps, it’s easy to make design decisions that you may not eve understand well enough to regret. I’m still a newbie in web programming, but my big lessons are (1) invest your human capital in a quality convention over configuration framework, and (2) get your database schema finalized and common queries working before you ever write any code.
