Doocreate: A boilerplate app to pivot Realities from?
Hugi Ásgeirsson
Public
Seen by 347
I've recently been talking a lot to our burner developer friends in Israel. They've created a task management app for co-created events that has a lot of similarities to what we want to do. I've deployed a version of it here: https://doocreate-hugitest.firebaseapp.com/task/3JeZwoephl7rj2b0pqA4
This is the repo on Github: https://github.com/Metaburn/doocrate
At the very least, we could re-use some of their React components and layouts as boilerplate. They have already built a lot of stuff we want, including some simple UX/UI elements and assigning users to objects, and they also have a working comment system which would be nice for us to include too!
However, they use Firebase. Looking at the future scope we would like to make possible (check the whitepaper: https://docs.google.com/document/d/1UcHQ1_thfNaUlEBcfz9PACd6_lXsj5F2lvV6RfG0oOA/edit) Firebase might not be a good data storage solution for us in the long term. They think that Firebase is probably not right for us, and would love to see what we come up with.
Gal, the main developer behind Doocreate, was also responsible for bringing Dreams from the Borderland to Israel. Collaborating with them again would be awesome, and if we build something great from their base that they can also use, we're likely to get an active base of developers in Israel working on the project too down the line.
How much of this do you think we could re-use? Perhaps we could even use Firebase to start with, though eventually I’d like to move away from it.
@emindurak, @erikfrisk, @gustavlarsson, @fredrikbranstrom1 – what do you guys think? How difficult would it be to build on this, and 1) reworking it to our model basted on need, requirement and dependency and 2) perhaps change the backend and database to something else than Firebase?
Hugi Ásgeirsson Sun 3 Dec 2017 3:42AM
Those are some very good points.
One benefit I could see with working from this base is that we would have a boilerplate to start from when we get going on Friday afternoon.
Setting up a boiler plate to start from would be good to do before we get going on Friday. How long would it take to get a boiler plate running with GraphQL, Apollo and our own backend in a repo that we could all work with next weekend?
Erik Frisk Mon 4 Dec 2017 5:20PM
@gustavlarsson recommended Next.js in the stack thread. I've never used it myself but it looks great. Using that I think we could have walking skeleton set up fairly quickly. I could make an offering of a couple of evenings to the Borderland God(esse)s before Friday and see if I can have something running. Would love help from some of the others if we can make it work with timezones (I'm in Colombia and 6 hours behind you). My boilerplate might not include a database if we want to use neo4j though. I've watched a few YouTube videos about it and it doesn't look so difficult, but since I have no experience with it it might take time to set up. The rest feels fairly easy.
Hugi Ásgeirsson Mon 4 Dec 2017 5:56PM
Awesome, I've replied more in the stack thread:
https://www.loomio.org/d/867aSKi5/choice-of-stack
Ronja Lofstad Sun 3 Dec 2017 4:30PM
Do you know how people use the app in practice? Do they use it? Do they miss some functionalities? Probably lots of valuable lessons to be learned from the project :)
Erik Frisk · Sat 2 Dec 2017 11:49PM
Thanks for the suggestion Hugi!
I've poked around in the code, and I'm not sure we'd save time lifting things over from their project. The part of their code that deals with Firebase and Redux isn't relevant for us if we go with GraphQL, Apollo and our own backend (which I suggest we do). In terms of UI, they've pulled in small stand-alone dependencies (e.g. react-select, react-toastify, etc.) rather than use a more full-fledged UI framework (@emindurak mentioned Semantic UI the other day for example). This is a legitimate choice, of course, but my vote is on using a more full-fledged UI framework. I think that would allow us to work faster.
We could probably lift smaller things over here and there, but we might end up spending more time figuring out how to reuse their code than it would take to simply write it ourselves using libraries that fit us better. We could probably reuse more of their code if we made design decisions more similar to theirs, but I don't think they're so far ahead that that is warranted. I say we do our own thing. It certainly doesn't hurt to have their code available in case we change our minds though.
This is just my humble opinion after looking at the code for half an hour or so. I'm always open to changing my mind if anyone has a good argument :)