search

mattkrick / meatier

:hamburger: like meteor, but meatier :hamburger:
3.05k stars 172 forks source link

Client cache options #45

Closed mattkrick closed 8 years ago

mattkrick commented 8 years ago

Client caching is painful right now.

Requirements:

Nice-to-haves:

Problems:

mattkrick commented 8 years ago

https://www.youtube.com/watch?v=S2Hp_1jqpY8 https://github.com/janmonschke/diffsync https://github.com/gritzko/swarm https://github.com/dominictarr/scuttlebutt

bartekus commented 8 years ago

What about local-sync? https://github.com/TechnologyAdvice/local-sync

mattkrick commented 8 years ago

looks interesting, I'll dig into the SC tonight, thanks!

bartekus commented 8 years ago

No problem and thank you for your hard work on this @mattkrick, you are doing incredible service to react/meteor community in particular and JavaScript community in generally! We salute you!

mattkrick commented 8 years ago

sounds cool, yeah it's MIT so have a blast. I still don't like the necessity of creating a reducer for each database table, but aside from that I think the stack is just about done. What do you mean "done with Anonymous in mind"?

mattkrick commented 8 years ago

Sounds great, keep me posted on the progress. Depending on how far you take it, it make just make sense to transform meatier into your stack, although with how fast this stuff is changing, I don't think any stack is going to have the sticking power that LAMP had... with so many combinations a stack is basically whatever your package.json is.

I only dropped the kanban in there to give myself a good 1:M relationship between 2 tables to work with (a 1-table todo list doesn't do a great job of showcasing how to handling relationships). Now that the folder hierarchy is modular, it should be as easy as deleting the kanban folder to get started.

jeffreywescott commented 8 years ago

It seems this conversation has wandered FAR off from "caching options". ;-)

mattkrick commented 8 years ago

@jeffreywescott haha yeah... blame @Bartekus :wink: probably easier to start a new thread now, but I'm still digging into it. I think I'm gonna have to write my own, which is lame. Digging more into relay it is one of the ugliest most convoluted APIs I've ever seen, but the power it offers is amazing. I think a lot of the complexity comes from being built on Flux (no middleware) and trying to do too much. For example, it handles the Loading, Error, and Result component. IMO it should pass those as props to the child it wraps & let the component itself decide how to handle the V in MVC, right now it's trying doing all 3 parts. It also makes you explicitly write out what the optimistic result would be... This is really brittle because state outside of relay might be based off the result.

There are some parts like the build-in pageInfo that are great answers to problems that have plagued web devs for years (eg are there more records?). Hopefully I can come up with something a little more powerful than Lokka with a cleaner API than relay, we'll see what happens this weekend!

ansarizafar commented 8 years ago

@mattkrick Please try to create GraphQL client with cache as a separate package without React or Redux dependency so that It can be used with other front end frameworks like Aurelia.

mattkrick commented 8 years ago

@ansarizafar it's gonna have a hard redux dep, which can be used with whatever. I love competition among front end frameworks, but just try & build meatier in aurelia... your initial client download is gonna be a monster. It still doesn't offer SSR (let alone streaming SSR), and async routing is...well, non existent last time i checked in on it.

That said, I totally agree the cache should be View layer agnostic (redux is in the model layer). Doing it this way opens up the door to neat things like predictive fetching (eg hover over a "get more" button & it starts downloading the results to the client cache)... but i've said too much :wink:

abastardi commented 8 years ago

Based on what you've built and learned, you might be interested in contributing to the discussion of Meteor's proposed new Reactive GraphQL data system: https://forums.meteor.com/t/reactive-graphql/17048. Looks like they're interested in ideas and feedback.

mattkrick commented 8 years ago

@abastardi It appears they haven't given the client cache any thought. Either they have to send graphQL + the entire introspection query to the client (HUGE payload) or they have to do what relay does & statically analyze the queries in a babel preprocessing step. The latter is the right way to do it, but it means exposing babel to the developer, which they still don't do in v1.3, right? I'll wait to see a developer preview before I pass judgement...

Out of curiosity, if facebook gives you your front end, your client cache, and your database connection, what is the value add for meteor? User Accounts?

bartekus commented 8 years ago

Hehe seems to me they want to walk into the hell paved with facebook's good intentions... Personally seeing what FB does in India with their attempt at recreating internet in facebook's image, I'm rather hesitant to completely buy into what they are selling :/

mattkrick commented 8 years ago

Facebook's business practices are atrocious. They read your texts, they track your movements, they watch you browse the web. To do so, they need to attract top talent. They do that by being a pillar in the OSS community. It's a damn shame that the brightest minds in the world are wasted on generating ad revenue, but at least some good comes out of it (namely react). I interviewed with a company that puts data miners inside browser extensions. Shady as fuck, but you'd get to solve the coolest big data problems you've ever seen...

mattkrick commented 8 years ago

@Bartekus oh dammit there you go getting me off topic again... CLIENT CACHE CLIENT CACHE. haha worst github issue ever :frowning:

mattkrick commented 8 years ago

You can move comments from issues to other repos??? I mean, it doesnt really bother me, but I kinda wanna see that now...

bartekus commented 8 years ago

Hey @mattkrick things got lighter here and we're back on track! :D You can remove your offtopic comments as there is backup in old tales under araphel now so as Buddhists say, all things pass away, but nothing is ever lost :D

mattkrick commented 8 years ago

:+1:

ansarizafar commented 8 years ago

@mattkrick Please visit the link to see the reply of @EisenbergEffect about Aurelia and Async routing https://github.com/aurelia/skeleton-navigation/issues/41#issuecomment-175034024

mattkrick commented 8 years ago

@ansarizafar that's not async routing as far as I'm concerned. When I say async routing, I mean triggering a module to download on route change. Effectively, it's turning a SPA back into a payload-per-route website, the only difference is the payloads are a LOT smaller (but require JS to be enabled). If you have an example of aurelia serving up a page via SSR and then downloading additional routes as tiny javascript fetches (including images, fonts, css, whatever), I'd love to see it. Until then, it can't really compete...

ansarizafar commented 8 years ago

@mattkrick I have used async routing with React-Router and Webpack, Its really amazing. Currently I am exploring other Front end frameworks. The ideas behind Aurelia are wonderful. Aurelia is in beta and we can't compare it with React at the moment though performance is already better then other frameworks according to this official blog post http://blog.durandal.io/2015/12/17/more-aurelia-performance-bug-fixes-docs-and-typescript-awesome/. Aurelia loader for webpack is not available at the moment. I am not sure how async routing will work with webpack that's why I asked Rob Eisenberg about it. He has also mentioned that Aurelia will have SSR.

mattkrick commented 8 years ago

For sure, I'm all about new tech that solves real problems & it's very true that people blindly swallow whatever facebook feeds them, so something outside the facebook (or google) ecosystem is always nice! That said, async routing & SSR was a hard requirement when building meatier. If aurelia can provide a solid community ecosystem with things comparable to material-ui, react-dnd, and graphiql, react-dom-stream, etc. I'm all for it! IMO, picking a frontend based solely on performance is a really dangerous form of premature optimization, since performance is easier to fix than the community.

ansarizafar commented 8 years ago

You are absolutely right. Aurelia Interface is a collection of Custom HTML Elements which can be used to build applications http://blog.durandal.io/2015/11/20/aurelia-beta-week-day-5-aurelia-interface/. I have found this few months old video in which Rob Eisenberg explaining ideas behind Aurelia https://channel9.msdn.com/Events/Seth-on-the-Road/DevIntersection-2015/Rob-Eisenberg-on-Aurelia

EisenbergEffect commented 8 years ago

If you guys have Aurelia questions, I invite you to our gitter room: gitter.im/aurelia/discuss You can also post issues on our repos on github. Let's not crowd this issue with Aurelia-specific discussion. I'm not sure the meatier team would benefit from that.

jeffreywescott commented 8 years ago

@mattkrick, since no one seems to want to talk about caching, but instead wants to talk about meatier in general, perhaps meatier needs its own gitter?

mattkrick commented 8 years ago

@jeffreywescott no kidding, I need to sit down & actually write cashay (the new client cache) so I can close this issue and keep it clean :smile: The gitter badge is the first thing you see in the readme... i think i need a bigger badge!

jeffreywescott commented 8 years ago

Maybe close and re-open this issue to re-focus it on caching, then encourage people to go to gitter?