Roadmap

[lvarayut]

Update: We stop supporting Yeoman for now, until we can find a good way to maintain it in our project, see more details https://github.com/lvarayut/relay-fullstack/issues/72.

Here is all the features planned to be developed. I list them out in order to make it easy for everybody to discuss and participate in the project. These features could be changed as needed, so don't hesitate to express your ideas. If you wanted to help developing some features, which would be very appreciated, please leave a comment below.

• [x] Example on Heroku @lvarayut
• [x] Official website (gh-pages) @lvarayut
• [x] Yeoman generator @lvarayut
• [x] Integrate css-modules @lexun
• [x] Mutation example @zenyai
• [x] Flow* @Neitsch
• [x] Data loader* @Neitsch
• [ ] Database integration* (MongoDB, MySQL, Postgres, and Cassandra)
• [ ] Yeoman sub-generators (Component, Container, Query, Mutation)*
• [ ] Testing framework (which one do you prefer: Jest, Mocha, Jasmine, Ava?) @lvarayut
• [ ] Server Side Rendering
• [ ] JSON Web Tokens* (Implement* Signup and Login pages) - This will be developed after Database integration
• [ ] Browsersync

*must be developed in canary branch.

[keon]

This is awesome, thanks for the project! But why Browserify when you already got webpack?

[keon]

Also when adding database integration, adding all the graphql schema and mongodb (mongoose, likely) schema into one folder seems to be counter intuitive. Why don't we split GraphQL schema into /graphql and database into database or conventionally called model?

So the proposed files structure might look like the one below:

   ├── models                   
   │   ├── index.js 
   │   ├── User.js
   │   └── Feature.js 
   ├── graphql 
   │   ├── schema.graphql
   │   ├── schema.js
   │   └── schema.json 

[lvarayut]

why Browserify when you already got webpack

Thanks for expressing your idea. Browserify was a typo. It meant to be Browsersync instead.

Why don't we split GraphQL schema into /graphql and database into database

Yes, when integrating the MongoDB, I have planned to restructure the schema/query/mutation structures.

[keon]

@lvarayut I can work on MongoDB and Mongoose part Please refer to my fork to see my proof of concept. (It might be immature as I am building it while learning graphql)

[lvarayut]

Thanks @keonkim. That would be great. Don't worry, take your time to learn GraphQL and complete your MongoDB in your fork. I can check it out afterward. However, you might also consider that do we really need to use Mongoose or just the simple MongDB driver is enough. Also, JWT is the preferable choice for authentication.

[AhmadEl-Banna]

@lvarayut @keonkim if you decide to go with MongoDb and mongoose ,have a look at https://github.com/RisingStack/graffiti-mongoose, I think it will remove a lot of redundant work with graphQL

[lvarayut]

@AhmadEl-Banna, Thanks for your suggestion. @keonkim has suggested it also. I'll take a look at it.

[sachgits]

Hi everyone love the progress been using these and after checking the Roadmap issue i wondered why not contribute to these. and by look of who is working on what seems like the JWT is open as it waits for the mongoDB (mongoose) database. i don't know much yet on JWT but i do research on it and take part on the login and signup pages that's if am welcome hahaha thanks guys

[lvarayut]

@sachgits, I would say that the JWT should be done after the database integration. If you could, please take a look at the database integration before digging down into JWT.

[sachgits]

@lvarayut ok let me do that also to add i think that they types should have separation inside of schema and with of which Persons Types, Feature Types node definitions and connection definitions should go separately

[lexun]

I've been enjoying Mocha for testing, and it seems to be the default choice in the React community these days (Just look through some repos here: https://github.com/reactjs).

As for database, I'd love to see the core of this boilerplate stay flexible if possible. I've been experimenting with some RethinkDB configurations and think there is a lot of potential there.

[lvarayut]

Thanks for your suggestion. Mocha looks really good to me. The project is currently split into two main branches; master and canary. The master branch always stays flexible as much as possible by containing only general technologies needed by all the projects. On the other hand, the canary branch is integrated with Yeoman, called generator-relay-fullstack, which allows you to choose technologies that suit your needs; Database, Flow, and etc. The generator presently works with minimal functionalities, a lot of things are coming up \ (•◡•) /

[lexun]

Any thoughts about using css modules? I'd be happy to cut a branch to show what it could look like.

https://github.com/css-modules/css-modules http://glenmaddern.com/articles/css-modules

[lvarayut]

That would be awesome!

[lexun]

See #18

[nodkrot]

How about https://github.com/Khan/aphrodite ?

[lvarayut]

@nodkrot It seems to be the same concept as css-modules except it's including everything in the same JavaScript file. BTW, @lexun has integrated css-modules which allows you to have a separate CSS file, and then, you can import it in your JavaScript which is more convenient, in my opinion. Most of the cases, you will have some business logic in your JavaScript file and you might not want to mix both styles and the logic together.

[mjurincic]

Database integration with classical RDBMS-es like MySQL/PostgreSQL would be also great, enterprise Apps still depend on them although NoSQL DB like MongoDB plays nice with mentioned graffiti-mongoose integration, there are projects already projects tackling those problems https://github.com/mickhansen/graphql-sequelize, maybe making it an option in Yeoman when scaffolding projects.

[lvarayut]

@mjurincic, that's a good idea. The database is totally optional and will be an option in Yeoman, generator-relay-fullstack.

[sachgits]

hey worked on testing barebones serverside might not be perfect yet but please take look at it and let me know what you guys think before i start on client side testing https://github.com/lvarayut/relay-fullstack/pull/19

[jonstokes]

Just wanted to drop in a note and say how much I love this project. I'm coming to react/relay/graphql from the rails world, and I've been looking for an opinionated generator that uses the same basic add-ons and tools I'm already using in my react projects (i.e. webpack, css modules, babel, etc.). So this is just perfect! Just looking at the generated default site has answered a bunch of questions I had about good ways to organize my code..

[lvarayut]

@jonstokes, Thanks for your kindly words! I'm very glad to hear that the project is useful to you. I will keep improving it and make it even easier to get started with Relay and GraphQL 🚀

[imzautomation]

Hello i am using relay full stack but I am facing some issues I have a django backend serving graphql endpoint at 8000 port I used graphene to build the graphql server by follwing the tutorial provided in Thierry website , I have a schema.json file generated and it resides in backend folder how do integrate this with this kit ? What changes do I have to make

[lvarayut]

@imzautomation Thanks for your question. Could you open a new issue and show your full error log?

[imzautomation]

@Ivarayut sure will do thanks

[Rohit-cheddr]

Any tips on how we can go about integration tests? It seems like the relay wrapper could cause issues if we do a full dom render.

[lvarayut]

@Rohit-cheddr, Unfortunately, we haven't explored the testing yet. Will let you know as soon as we can.

[Extra-lightwill]

@lvarayut Add Cassandra to database integration?

[maksugr]

Do you think add react-mdl as default dependency is a good idea? It's seem like personal preferences.

[maksugr]

Have you thought about implementation additional flux implementation (Redux?) for local state? With Relay it's difficult to work with local state that coming not from Relay (client side authorization and so on).