Should we use Laravel?

[gilbitron]

As we kickoff the roadmap for SqlBuddy v2.0 we need to start somewhere. @bradt suggested using Laravel as the framework to build the app, however I'm not convinced that's the best way to go as Laravel isn't really setup to be easily distributable. For example:

• Laravel has fairly high requirements, which makes for good developer UX but poor compatibility
• Laravel is designed to have a vhost pointing to the /public subfolder
• Laravel relies on lots of external composer packages which would need to be bundled with releases?

I think a requirement of SqlBuddy is that it should be super easy to install (e.g. drop it in a folder and enter a few config options), otherwise we risk poor adoption rates.

Thoughts @deliciousbrains/employees?

[polevaultweb]

I would imagine whatever we build it with would involve some Composer packages, so we would just need to include the vendor dir in the distributable build.

[A5hleyRich]

@gilbitron I thought the same when Laravel was initially suggested. Could we not just grab individual Symfony components as required and distribute the vendor dir as Iain suggested?

I think if we want to be a competitor to phpMyAdmin we need to make the installation as easy, if not easier.

[bradt]

Ah, I've never developed with Laravel so didn't realize. Good points. Ash's suggestion sounds good.

[bradt]

Apparently an outdated framework was one of the major reasons for the scuttling of this SQL admin project: https://github.com/fusonic/chive/#announcement-july-2014-chive-is-no-longer-actively-developed--maintained

[JRGould]

It might be good to define some minimum requirements that we want to adhere to at the get-go since that will greatly inform our dependency selection.

[ianmjones]

Yeah, this is what I was trying to say in the meeting, it wasn't just a case of "tabs vs. spaces" (should be tabs by the way).

Laravel is great, for full web apps where you have control of the infrastructure and can satisfy its dependencies, but it's just too much for an app that needs to work on a variety hosts and should be an unzip and run setup.

I agree with @JRGould, would be nice to peg some basic minimum requirements. We should shoot for the current "norm" for things like minimum PHP and MySQL versions so that we can get good buy-in from the get-go. We can always increase the minimum requirements on the next major version change.

Would be very keen for us to use a good component layout on the frontend, maybe Vue.js is the right choice for that.

[bradt]

I've opened another issue to discuss frontend frameworks: https://github.com/deliciousbrains/sqlbuddy/issues/13

[bradt]

So I guess we each figure out which PHP features we'd cry if we couldn't use and then dial it up from there.

[A5hleyRich]

Symphony requires PHP 5.5.9, which is higher than I originally thought. That said, PHP 5.5 reaches end of life a in a few months.

http://symfony.com/doc/current/reference/requirements.html#required

http://php.net/supported-versions.php

I would say 5.5.9 is reasonable and that we shouldn't advocate anything less.

[gilbitron]

Thanks for your feedback guys. I agree with everything thats been suggested.

I was thinking the same thing that @A5hleyRich suggested, basically building a custom, lightweight framework from Symfony components. I didn't realise Symfony required PHP 5.5.9+ which is higher than I expected (I was going to suggest PHP 5.3+ so we could at least use namespaces) but maybe it would be better to encourage a slightly higher version of PHP.

WordPress requires MySQL 5.6+. Are we happy with that as a minimum version for MySQL?

[gilbitron]

I'm calling this a consensus and closing this issue as it's now been implemented as part of https://github.com/deliciousbrains/sqlbuddy/issues/14.

[ianmjones]

I'd like to re-open this discussion, it feels rushed to me and I have another proposal for the backend framework.

Although we all seem to be fans of it and using it for other projects, we all agree that Laravel is just a bit too heavy for our needs. But what about Lumen?

From what I can tell, it would work great as a backend framework for serving JSON to a SPA built with Vue.js. It is much more lightweight than Laravel but uses a good chunk of its core, and is familiar to developers using Laravel for that reason. This means it will be easier for others to contribute to SQLBuddy as there will not be the hurdle of a custom framework to get over. We can point people to the Lumen docs when getting started.

It also requires PHP 5.5.9 as a minimum, which is fine as that is currently the oldest version still getting security releases (for another 2 months at least).

I'm keen that we don't build a custom framework that to all intents and purposes is going to do what Lumen already does. I'm also very aware that this is currently something we'll work on in our spare time, so it makes sense even for us, let alone other contributors, to have something we can get stuck into quickly and produce real value rather than ramping up a custom framework too. Not to put words in his mouth, but I suspect this is the reason @bradt suggested Laravel in the first place.

Another reason for using Lumen is its support for MySQL, Postgres, SQLite, and SQL Server, which makes me happy. 😄 I'd personally like SQLBuddy to at least have the ability to do some basic work with databases other than MySQL in the not too distant future, would make it useful for migrating data between different database servers.

[gilbitron]

You make a good point about developer adoption @ianmjones. I thought Lumen took a "just for API services" turn recently, but it looks like it probably would still be a good fit for what we need (as it does what my custom framework does but better).

Another reason for using Lumen is its support for MySQL, Postgres, SQLite, and SQL Server, which makes me happy.

I planned to use DBAL which would support this anyway, but Lumen had it baked in.

[ianmjones]

I thought Lumen took a "just for API services" turn recently

This is the exact reason why I think Lumen would make a great framework for us. If we use it correctly we can have complete separation of UI and backend, with the Lumen powered backend providing a JSON/REST service for any frontend. We'll just happen to bundle a Vue.js powered frontend by default.

If we make sure there is no dependency between the Lumen backend and Vue.js frontend other than the Vue.js consuming the JSON API that the backend exposes, then we'll have no trouble switching to a different frontend in the future should Vue.js fall by the wayside. And the same goes for switching out Lumen for another framework that allows us to create a JSON API on the backend should there be issues with it in a few years' time.

I'm also keen that we be able to properly test the API rather than traditional unit tests, it would be awesome to have acceptance tests that exercise the API so that we know it does what we expect it to do, and having that separation of front and back ends makes this much easier.

Lastly, it would be great if it was entirely possible to create a completely different frontend using the exposed JSON API, so that a secure connection to the service could be used by a desktop app, mobile app, CLI, or whatever, without having to expose database specific ports, and allowing for aggregation of database access by the service.

[bradt]

I suspect this is the reason @bradt suggested Laravel in the first place

Correct.

While I'm not against building the new SQL Buddy with a services-oriented architecture (SOA), I don't see why having an API is an argument "for" this. If a user blocks the database port for better security, why would they allow the SQL Buddy API outside access? If they're willing to give the SQL Buddy API access, they could just as well allow access to the database port and use an existing client (e.g. Sequel Pro) that connects on that port. The main utility of phpMyAdmin and its competitors is the UI. That's why people install it.

I guess if a user is installing it on their hosting provider where they don't have control over the port and then could use the API to run a desktop client, that would be pretty useful. Though I could see web hosts catching onto this and shutting it down at the server or network level.

If a SOA is the best way to go for other reasons (i.e. works well with Vue.js) though, go for it.

[ianmjones]

Quorum met on using Lumen framework for 2.0.