Roadmap

[larixer]

General roadmap for upcoming Apollo universal starter kit features, and a priority they'll be approached.

Feel free to suggest any features you'd like to see in this thread, and they'll be considered for inclusion.

Done

• Integration tests for Counter UI
• Integration tests for Counter backend
• Integration tests for Posts and Comments UI
• Integration tests for Posts and Comments backend
• Look if we can integrate React Native into this starter kit
• Show Expo QR code
• Embedd LAN IP into Android and IOS bundles in dev mode to route GraphQL requests to backend without need for additional configuration
• Adding source maps to React Native build process
• Add docs explaining how current implementations works
• Exit with error on attempt to launch Android and iOS at the same time since Expo doesn't support this
• Add CLI command to add or delete a module
• Add React Navigation
• Convert Post example to include universal/native + web presentational components
• Generalize and move out build infrastructure into separate package
• Authentication and authorization example
• Add Flow typechecking
• Keep Redux state on Hot Module Replacement
• Image upload feature (Apollo upload #421)
• Add basic filtering and sorting options to the user list page (Implement basic Admin Dashboard #420)
• Integrate Apollo Engine (Add Apollo Engine support #423)
• Move backend, web frontend, mobile frontend into separate Lerna packages (Yarn Workspaces and Lerna Support #575)
• Internationalization and localization support (Internationalization #677)
• Port user module to React Native (Implement authentication across all platforms #644)

Soon

• Create Angular4 + TypeScript version of the kit ([WIP] AngularJS version of the kit #354)
• Integrate Ant Design Pro template into the kit (Integrating Antd Design Pro #554)
• Refactor post module (nested mutation / merge post_add + post_edit) (Post module refactor #322)

Future

• Make persisted queries work with React Native
• Add documentation website

[mairh]

Feature request: I18n localization (translation) support

[larixer]

@mairh Yes, i18n is a good one. Will add this feature to the list. We have experience with this on our project where we use this starter kit, so we can relatively quickly transfer code for basic i18n support here via react-intl, but there will be more work involved to add i18n into Posts and Comments and Counter example...

[lxwbr]

@Vlasenko did you guys manage to get react-navigation running together with expo?

[larixer]

@Zunder Alex, we haven't tried yet. Are there any problems with adding react-navigation?

[lxwbr]

@Vlasenko Yes, after fiddling around with different versions of expo, react-native and react-navigation, I finally got it to work. Only thing left is a warning: Possible Unhandled Promise Rejection (id: 0):, which I am having difficulties to track down.

I have slight suspicion that it has something to do with AppRegistry, but nothing sure yet. I am not 100% sticking to this kit though as I am using an additional typescript loader. I doubt it being a reason for that warning though.

Anyway, my hopes where that I could find an example of using the react-navigation as this kit is the closest getting to my use case. Guess I have to wait a little more.

[larixer]

@Zunder Lets discuss in the chat:
https://gitter.im/sysgears/apollo-fullstack-starter-kit

[justinr1234]

How do you feel about Nativebase @Vlasenko ?

[mitjade]

@justinr1234 Currently I am in the process of making post example work in React Native. When this is done, I intend to evaluate UI components that might be useful for this kit. Nativebase looks promising.

If others agree we can add it to the Roadmap.

[justinr1234]

@mitjade I actually already integrated it if you'd like me to PR. I'd need to do some work to get the examples updated (as you're doing). The hard part was making sure to integrate the proper versions and settings of everything for Expo. Had an issue with loading the proper font files for icons and whatnot.

[mitjade]

Having a PR for this would for sure be useful if anyone else is interested in this.

If we then merge it, @Vlasenko and @mairh need to add their opinions here if this is the direction we want to go.
The problem is that there are many UI components out there and there will always be different preferences what to use. Currently we try to pick the most popular one. I personally use AntD for web.

@Vlasenko is in the process of making this kit more generic by splitting certain parts into separate packages. I guess this is one of the areas that apply here as well. Problem then arrises on how to maintain all different variations.

[larixer]

@justinr1234 I agree with everything Mitja told above. Pull Request for supporting NativeBase would be nice to have. I propose to keep solutions to override framework choices in Pull Requests and let people use them as a guide

[mairh]

Nativebase is nice to have. Since our philosophy is to get the full working app ready quickly from ground-up with lots of features rather a mere skeleton boilerplate. I guess Nativebase will help us in that direction.

[mairh]

Another option is to integrate Shoutem UI. Although, both nativebase and shoutem are more or less the same. I personally believe the default UI (no customization + theme) is better in the case of shoutem and looks pretty nice. Moreover, integrating themes are much easier (only one place to modify) in case of shoutem.

[seanscal]

Feature Request: login/registration

[larixer]

@seanscal This feature is already in the list:
"Authentication and authorization example"

[seanscal]

ah jeez didnt see that, awesome!

[justinr1234]

@Vlasenko Re: UI packages. I was contemplating the ability to swap between UI packages via the app.json. Something like:

{
  ...
  ui: {
    web: 'react-native-web',
    ios: 'native-base',
    android: 'native-base'
  }
}

Where then you could use something that happens via webpack to dynamically include/exclude a specific version of something like button.js dependent on the UI you're wanting to use. That way we're not bundling multiple UI packages into the resulting output, but can still configure what UI you want to use for the kit via the app.json. Would need to flesh out technical details more fully, but I could see it being pretty cool rather than doing something more confusing by having multiple repos or forks that have to be kept in sync and will (I believe) inevitably drift.

[larixer]

@justinr1234 Technical support of this stuff will be implemented in:
https://github.com/sysgears/spin.js
In spin.js you specify your stack for each platform and all the build rules are generated on the fly for the stack you have chosen. Check out this Pull Request:
#314

[larixer]

@Zunder @mairh @mitjade Build infrastructure has been moved out into separate npm module: spin.js. This opens way for radical customization of this starter kit, including TypeScript support and multiple UI support. One will only need to write spin.js plugin like this: https://github.com/sysgears/spin.js/blob/master/src/plugins/StyledComponentsPlugin.ts
and add example code to the kit

[justinr1234]

@Vlasenko Looks powerful, but to be honest it's kind of confusing at first glance. Do you plan to add some more hand holding to the examples?

[larixer]

@justinr1234 Yes, sure. I plan to add more thorough documentation

[mitjade]

@Vlasenko Fantastic! Will try and play with this today.

[mairh]

@Vlasenko What do you think about file upload feature in the kit? Doing file upload using graphql mutations could be a good addition we can offer in the kit. We could just simply start with blob in the image folder. Later we can integrate cloudinary / S3 or some other services to store and host the images. Usually, if someone have auth feature in the app most of the time apps also provide user image upload or image upload in chats/comments.

[larixer]

@mairh Yes, it would be nice to add

[mairh]

Alright. I will add that in the roadmap description and work on it later in the week.

[justinr1234]

@Vlasenko https://github.com/wix/redux-testkit

[justinr1234]

@Vlasenko Thoughts on this? https://github.com/charlieschwabacher/gestalt/blob/master/docs/getting-started.md

I particularly like the neo4j borrowing for automatically defining of relationships and join tables ...

[larixer]

@justinr1234 Yes, it looks interesting for quickly generating API and GraphQL schema. I think one can use gestalt for generating backend and build web and mobile frontend with this kit.

Of course if one could generate server modules for the kit using gestalt, that would be the best integration, but this will require some effort to implement I think.

[aneilbaboo]

I'm here to add my vote for more documentation. (IMO, the most important next item for the roadmap). I created an issue asking for documentation of the Feature class #565. I also like the suggestions in #393.

[simonjoom]

what do you think about apollo-prisma approach? will reduce lot of code (mysql ) i guess and simplify
i don't know knex .. and looking through this repo, afraid me to have a start with

[larixer]

@simonjoom Yes, but this will come with worse customization options. Right now the code is totally flexible. We can have separate Prisma-powered backend in the kit if someone be willing to maintain it. The direction we are going to move and maintain is CLI crud:
#732