Convert Redis to MySQL

[davidnknight]

Hi guys,

What do you think to converting LaravelSnippets to only use MySQL rather than MySQL and Redis? I think that we'll open it up to more contributors by just using MySQL.

[johnnncodes]

Hmm, what do you guys think? @chrispitt & @ionut-tanasa ? If majority wants to remove the Redis dependency, then I'm fine with that.

[johnnncodes]

Anyway, just wanted to note that I think having Redis as a dependency doesn't really get in the way of attracting more contributors especially now that we have a Vagrant + Puppet setup. And soon when we implement search feature on the site, we will add another dependency w/c is elastic search but it won't be a problem again because of Vagrant.

[assertchris]

I agree that it would encourage more contribution. Redis is a black box for the majority of beginner-to-medium Laravel developers. Let's be honest; we would be lucky to get more contribution from advanced Laravel developers, so is makes sense to lower the bar for entry. That doesn't mean we allow sloppy code to hit master - it just means we make it easier for more developers to submit code.

There are other benefits too:

• fewer tests need written
• vagrant up is quicker
• manual setup instructions are shorter
• tech stack is simpler to explain

It would have my vote, if we were voting on it... :)

[assertchris]

It may be easy to fold these things into Vagrant, but that leaves manual setup, knowledge of how to use these technologies (in PHP) and debugging them...

[johnnncodes]

Fair enough :) Let me +1 this proposal too :)

[assertchris]

It does pose the question: when do we decide that new technologies are allowed to be added? Should we really be doing ElasticSearch or would MySQL-only search suffice?

[johnnncodes]

Honestly, I'm not really sure. In my opinion using technologies like Redis, ElasticSearch etc... in this project also has benefits like it will serve as a code sample/reference for others on how to use or integrate these technologies to Laravel or PHP and being able to add these technologies lets us use the right or better tool for the functionality we need. But its true that it also has disadvantages because the project will be harder to setup if other people want to setup the project manually and it makes the project more complicated for others. Would be interested to hear your thoughts or suggestions about this. /cc @davidnknight & @ionut-tanasa

[davidnknight]

It's difficult I suppose as there are benefits to both. I just thought it would be simpler, less pieces to the puzzle, less for people to know and/or learn. If we set the barrier too high, we won't get as many contributors, but there's also no guarantee that more will contribute simply because we lower it.

Perhaps it's best to do what's right for the project / site and not worry about contributors so much, and then we can use the technologies that we want to, which will improve the site's functionality, search etc over what we could achieve with just MySQL.

[ghost]

I would keep using Redis & add Elastic.

Why?

I think we should think what are the best choices for the app, and not for the contributors' programming skills.

Yeah maybe we'll get less PRs but until now I don't saw any besides ours. So I wouldn't bother "semplifying" the app further. Just make it better and better. Add every kind of third party apps, libs, services etc makes the app really good.

I'm for keeping it as it is now.

But obviously it's not a must. We could also lower the difficulty, of course, but I'd like it the way it is now.

[wlkns]

Hello, new to the repository.

I think its a valid point of doing what is best for the app, however, I can only see Redis being used in 4 places for a hit counter, which has some overhead in itself with the way it is being used. E.g. ORDER by FIELD(id,1,2)... so I would vote for going back to MySQL with a delayed update on the hits field.

Are you intending to use Redis in more places?

[davidnknight]

Guys? Can we decide on this so we can close it?

[assertchris]

Let's leave it. :)