Closed snordmann closed 5 years ago
I like the idea of NoSQL. I did a bit with Firebase and it was cool but depending on how we want the DB hosted and accessed, Mongo may be better.
For the webserver my vote is on Express, mostly because I've used it before but also because there is a good amount of documentation and information available for it, this would make things easier for the community to contribute.
for testing and deployment, I don't have much to add because I have not done them myself nor really seen them done. I'd be happy to conform with whatever standard is set.
I second both the backend and db choices of Express and MongoDB. I am most familiar and comfortable with these platforms.
Testing I am a beginner at so no opinions.
Firebase however has the appeal that we can easily use the same platform for authentication, database, analytics, and much more without multiple libraries. Express is an excellent choice for most apps.
graphQL seems to be the way of the future, should we try to push that into the tech stack? i like what ive been hearing about it but how ready is gql for production at this point?
I would vote on - SQL (any flavor) Express Mocha Chai CircleCI
@spiray I vote same. however I would switch SQL with NoSQL, In any case, that's a nice combination.
Time to throw my hat in the ring:
I haven't really used any framework extensively other than expressJS. I could give some first impressions like that Koa looks nice and that I really like the modular approach the developers are taking or about how easy it was to get started with restify. But I think for convinience and familiarity inside our development team as well as outside contributers express is the way to go.
I think I have seen CJ using a mocha/supertesting stack for testing an api. The products work really well together and can even include code coverage reports with the nyc
cli from istanbul.
However I also see the benefit of having one testing platform like Jest that can provide everything with one tool. This will (hopefully) simplify CI and local testing.
When using Jest we can still use chai as assertion library, but I would suggest using the provided assertion library just to not have new contributers looking in different documentations not even knowing which tools is causing the error.
I just realized we won't even need supertest but rather use supertest to get the response ans run assertions on the respone object.
I personally have only used Jenkins on self-hosted machines. I don't know if there are any Jenkins cloud offers and if they exists I suspect they'd cost a lot of money. I must say: Jenkins is awesome. It can do almost everything and it integrates with everything. But I think for this project Jenkins is not the right tool.
I haven't used CircleCI yet, but a quick serach revealed that we could even use the free plan. And having CircleCI running in the cloud we do not need dedicated servers (thus saving money and time).
In my opinion we should start using CircleCI and see where thaat leads us. If we need more customization we can still migrate to Jenkins.
We need to define our requirements first and then check which cloud provider is the most cost effective. I would leave the decision on the deployment and cloud provider as the last one, since the technologies used determine the requirements (Are we hosting the DB ourselves, Do we need dedicated machines for external programs, how do we backup our data, etc.)
Agree with most of the stuff @sbibow mentioned, as a beginner, I can relate to most of what he said.
For testing, Jest has an assertion library called Assert built in, I think it's possible for Mochai to also use it but like he pointed out, it's better to use one tool rather than multiple ones.
I only have experience using Express and MongoDB with Mongoose for schemas. I feel like both of those are good options, as they are well documented and generally easy enough to use.
It should be entirely possible to use nested/sub-documents for the bulletin board/Find a pair, which I feel like would be the feature that would benefit the most from a relational database. It's possible to use a hosted MongoDB server at https://cloud.mongodb.com/ and I've been happy with it so far. It's easy to set up, and stats and so forth are included. I haven't used firebase, but that sounds like a good solution also.
As for testing, I've used both Mocha + Chai and Jest. I prefer the setup of Jest as it seems to just work out of the box, although Mocha + Chai would be fine as well, and they also have plenty of documentation out there.
I just found this for node which seems like an interesting, lightweight, and easily followable testing library: https://github.com/avajs/ava
I'm sad to admit but i've but written a single test before. So i am interested in learning, just never went that far on a personal project. I hear good things about Jest.
Agreeing with @afbk 👌
@afbk Mongoose is nice. Never had experience with it, just went through the docs and it seems to be straight forward, I'm okay with it don't know about the rest though. @Sharpie360 Writing tests isn't that hard from what I've seen on CJ's livestreams. We just don't have experience, but I believe we'll pick it up quickly. Difficulty is just a matter of what library we are going to use.
Hello everybody,
it's time to get these discussions to an end. I will summarize all available votings options in this comment.
But first let me talk about what does not get voted on:
With costs in mind and what services are easy to use now.sh is the service we deploy to. They offer serverless deployment meaning that we would not have to worry about server operation at all.
As already established there are a number of CI tools on the market. However CJ and I decided on using Travis CI. The two reasons are that it is completely free for open source projectsand that Travis is really easy to get into.
It will still be possible to vote on either an relational database model (SQL) or NoSQL database. However where it is hosted will not be up for discussion. Based on the lowest price for our requirements we wither use mLab as MongoDB host or Amazon RDS for a SQL database. Firebase can still be used but is not our primary choice since it require a lot of configuration for the database rules.
And now to the things you can active shape by participating in a poll. The poll will be posted on Discord as soon as possible, we will go there for voting.
As explained above we still can chose a traditional RDBMS, go for a schemaless NoSQL alternative or use firebase as a persistent data storage.
Possible choices:
- SQL
- NoSQL (MongoDB)
- Firebase
Since everybody in this thread wanted to use Express I just have two choices for this poll. Either express (duh) or something else.
Possible choices:
- ExpressJS
- Something else
Here I have heard some different frameworks but it mainly boiled down to mocha+chai or Jest. We also had the suggestion to use ava but I will file it under "something different" since it was only mentioned once (sorry @joshuaferr1s). Since we also want code coverage reports and targets we will need to add istanbul to the mocha+chai toolchain.
Possible choices:
- mocha + chai + istanbul
- Jest
- Something else
That's it for the things we will vote about. If I missed anything please add a comment below and I will adjust this comment. The actual vote on Discord will follow in around a day.
Have a great day 😊
Thanks for doing this! You really took the discussion into consideration which can be difficult. (No hard feeling about Ava I have never used it just found it 🙂)
Alright folks! it looks like the results are in and we have our tech stack chosen. Big tahnks to all that threw in their thoughts and opinions! If you have any questions or want to check out the results, visit the discord channel. /polls
Hello together,
This issue is to hold a discussion about which frameworks to use. The scope of this issue is to decide on how the backend works.
Database
Webserver
Testing
Deployment
Feel free to comment on this issue and start a discussion on which framework / program to use. If I missed any app just leave a comment, I will add it as soon as possible.
Cheers, Semjon