is there a plan for a new release in near future?

[emmlopez]

Hi,
sorry but I was not sure where I could ask this questions, I would love to start using falcor in our project but in order to sell it to management, I would like to ask if there are plans for new release , what other companies are using it for production, it seems no activity for a while, is there a reason ?
thanks in advance

[morious]

Does 20 days of silence means no?

[falcor-build]

Hey sorry about the delayed response. We are planning a new release. We've been very busy lately on ports of Falcor to iOS and Android. Expect to see more focus on the JavaScript version over the next couple of months.

JH

On Jul 20, 2016, at 1:26 PM, morious notifications@github.com wrote:

Does 20 days of silence means yes?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

You received this message because you are subscribed to the Google Groups "Falcor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to falcor+unsubscribe@netflix.com.
To post to this group, send email to falcor@netflix.com.
To view this discussion on the web visit https://groups.google.com/a/netflix.com/d/msgid/falcor/Netflix/falcor/issues/800/234071077%40github.com.

[eddieajau]

Jafar is there any way we can help with either the development or direction of Falcor? I love the JSON graph approach, but there are things about the current implementation that are a bit frustrating when it comes to scaling Falcor in large applications (for example, the router doesn't lend it's to modular/pluggable paths, it's difficult to test because of how this is handled, a sane approach to error handling still needs a lot of work, etc).

Thanks in advance.

@emmlopez I'm using it in production so if you want any information to sell it to management let me know.

The big positives is the client just has to learn to traverse the JSON graph, not a telephone directory of API's to call. The other huge thing is I can build out tree "leaves" before I build out the trunk. For example, we have an articles and category system. Articles are always in categories so that routes will be something like categoriesById[1]articles[0..9], but what cool is that I've been able to build the POC articles service and have it wired up to the UI without having to actually implement the categories microservice itself (that can happen in a future sprint).

The (current) big negative is that the Falcor router needs to be built monolithically which messes up our really nice microservice architecture. At the very least the router needs to expose an addRoute method (happy to help if I can get some guidance on how Netflix would want to implement that) but I'd also like to find ways that we could dynamically add route handlers (perhaps from another microservice) on the fly.

[morious]

JH - Thanks for the Update!!!

@eddieajau - could i ask you please to elaborate some more about the big negative you described? What is the use case?

Thx!
MM

[jhusain]

One of the areas we are currently evaluating is how we can improve error handling. We will be putting a proposal forward as an issue so we can gather feedback on it.

I'm curious what you feel about the current router design forces you to build things monolithically? Why not simply put individual routes in their own modules and import them
into a single router? Is it the use of the "this" object by the routes? Would you prefer some sort of context object to be passed in as an argument?

[nicovalencia]

@jhusain very excited about work on the iOS/Android clients. If you'd like assistance, testing help, etc. please let me know. We've implemented a temporary de-referenced JSON tree approach for the time being (thanks @greim).

@emmlopez we use Falcor in production. If your company/product goes down the route of implementing an SOA, you will likely hit a point where a single decoupled aggregation layer is necessary for performant clients. If you begin de-duping/data splicing service responses, you'll likely end up with a graph-like data store anyhow. At this point you've just built a core part of Falcor and/or GraphQL, so why not leverage and contribute to one of those existing projects?

I think the biggest issues you might run up against right now are complex association-based create/update calls (which are going to be complex no matter what), and verbose client-side data fetching (which can be abstracted, and is far worth the granular data fetching for performance IMO).

[trxcllnt]

We're also using falcor at @graphistry, and I've put in a request to join the falcor github team again so I can help respond to issues and merge PRs when the Netflix team is preoccupied. Additionally, I've also offered to help with some of the new development I understand might be planned. I don't expect the projects to be abandoned by any means.

[eddieajau]

current router design forces you to build things monolithically

@jhusain so what we have are a collection of backend microservices, and then we stand up Falcor as a microservice as well. Because we use Crossbar, each microservice can dynamically register it's RPC end-points with the WAMP Router (Crossbar). So for example we have a microservice for each of Articles, Categories and Users, plus we have a Falcor microservice.

The Falcor microservice registers model.json.get, model.json.set and model.json.call with Crossbar when it spins up. The disadvantage I mention is that I'm forced to build the Falcor microservice monolithically to support all our microservices. I'm happy to pay that price for now, but it won't scale well when we start including dozens of modules. While Crossbar easily allows us to stand up new backend microservices dynamically, we have to rebuild the Falcor microservice each time we make any change to any part of the JSON graph.

Our situation is compounded by the fact that:

1. One application is built up on many Netflix-size modules.
2. We provide one application stack that is tailored per client.

The first step forward would be to allow an instance of Router to have an addRoute or addRoutes method so that I can add routes at any time. Currently I'm forced to assemble all my routes at start time. I still might not solve full dynamic routes, but at least I could make my bootstrap code a bit neater for each module, for example:

import routes as "./articleRoutes";
export function registerArticleRoutes(router: Router.CreatedRouter) {
  router.addRoutes(routes);
}

And that Router.CreatedRouter type definition is ugly-as btw ;) Not a high priority, but that needs to be fixed sometime :)

Is it the use of the "this" object by the routes?

I've tried to explain the this problem here. I know JavaScript allows you to employ magic like this, but it's a pain in the backside for doing elegant TDD.

[przeor]

@eddieajau add routes, arrow function that returns concat arrays is not enough? Check how I handle this:

export default ( req, res ) => {
  let { authorization, role, username, restaurantid } = req.headers;
  let userDetailsToken = username+role+restaurantid;
  let authSign = jwt.sign(userDetailsToken, jwtSecret);
  let isAuthorized = authSign === authorization;
  let sessionObject = { isAuthorized, role, username, restaurantid };

  let routes = [
      ...staffRoutes,
      ...emailRoutes,
      ...profileRoutes,
    ]
      .concat(newsFeedCallRoutes( sessionObject ))
      .concat(newsFeedRoutes( sessionObject ))
      .concat(managerLogRoutes( sessionObject ))
      .concat(managerLogCallRoutes( sessionObject ))
      .concat(trainerLogRoutes( sessionObject ))
      .concat(trainerLogCallRoutes( sessionObject ))
      .concat(restaurantsRoutes( sessionObject ))
      .concat(emailTemplatesRoutes( sessionObject ))
      .concat(loginRoutes( sessionObject ))
      .concat(itemsRoutes( sessionObject ))
      .concat(itemsCallRoutes( sessionObject ))
      .concat(sectionsRoutes( sessionObject ))
      .concat(sectionsCallRoutes( sessionObject ))
      .concat(menusRoutes( sessionObject ))
      .concat(menusCallRoutes( sessionObject ))
      .concat(trainingItemsRoutes( sessionObject ))
      .concat(trainingItemsCallRoutes( sessionObject ))
      .concat(trainingSectionsRoutes( sessionObject ))
      .concat(trainingSectionsCallRoutes( sessionObject ))
      .concat(trainingMenusRoutes( sessionObject ))
      .concat(trainingMenusCallRoutes( sessionObject ));

@eddieajau are you looking for something more specific? Does it solve your problem?

[gyllen]

@falcor-build Will ios and android ports be available publicly?

[jhusain]

At the moment we'd like to find more time to devote to supporting our web version, so I think it will be a while before we consider releasing another version into the community.

[gyllen]

@jhusain Is there anyway you will let the public into the iOs and Andriod clients? I really do believe in what you guys are working on, its a beautiful concept, we have cut our client calls with high numbers over at Mapillary AND angular2 + falcor is kind of the perfect match.

However to fully leverage falcor I do think the iOs and Android versions needs to be out there.

[hipkiss91]

@falcor-build How goes the building? Possible to see a javascript release before Christmas?

[sdesai]

We'd like to aim for one. It would likely be close to what is on master. We're just trying to set aside some cycles to make sure the new version of deref() on master is the right way to go, in an attempt to avoid more churn on that API. The current implementation requires us to add meta-data to the JSON payload users obtain from get, so we'd like to make sure that's the right trade-off (the 1.x docs have more details).

[gyllen]

@sdesai I hate bugging you guys about this but do you have any plans on making the Android/iOS libraries public?

[sdesai]

@gyllen - Definitely not bugging us. We actually need to get more traction against visibility and progress for the project, so folks don't have to ask, so that's on us.

There are no plans to open source the Android and iOS clients currently. There's a decent amount of effort to get them to be feature equivalent to the JS client and ergonomic for end users, for wider consumption [ they work off an older/early version of the JSONGraph for example ].

Any available resourcing we have would probably be directed to the JS client (getting the new version out, making headway on the backlog of issues/prs) and NodeJS router first.

[Hagbarth]

Just wanted to chime in.
It's reassuring that you are working actively. I was starting to get kind of worried (based on activity graphs etc.)

Would love to contribute with w. issues if there is a need ?

[kvreem]

iOS port of Falcor highly demanded, would love to see if there is plans to open source that portion of Falcor, thanks Netflix!

[sdesai]

Hi, sorry, currently we don't have plans/the bandwidth to open source an iOS or Android client. Our resourcing is currently focused on the server side of Falcor (the router/datasource, and a way to chain and transform JSONGraph responses across routers/datasources optimally/ergonomically). Any resourcing around the client side of Falcor would probably go towards the JS Model/Client.

[sdesai]

We just released 1.0.0 for the JS Model/Client. Sorry, but as mentioned, we don't have any plans currently to open-source the iOS or Android clients (just a function of resourcing, and the fact that we're focused some internal server side work currently).

[gyllen]

@sdesai Thats a bummer, its great that you release 1.0 for web but I think for Falcor to really take off we need Falcor clients for other systems too. I think Falcor is far superior to GraphQL that is winning this API battle now cause lack of just more platforms for Falcor.

Having that said Im impressed by the deep thinking you guys have done to get together such an awesome framework!

[peterneubauer]

@sdesai what help do you need for Android to make it oss? We are forced to use Rest over falcor just to provide an api that people and apps other than Javascript can connect to. Happy to help.

[sdesai]

@gyllen @peterneubauer Thanks for the kind words and offers to help.

Currently, both the iOS and Android clients which Netflix uses are aren't canonical, standalone, library implementations. We plan to spend some time over the next few months, extracting the implementations into standalone libraries, and establishing parity with the specs and documentation you see here. Once we've broken out the canonical implementations, happy to re-engage to see if it makes sense to put them out here.

[peterneubauer]

That would be fabulous! We at Mapillary would love it.

…

On Mon, Oct 2, 2017 at 8:17 PM, Satyen Desai ***@***.***> wrote: @gyllen <https://github.com/gyllen> @peterneubauer <https://github.com/peterneubauer> Thanks for the kind words and offers to help. Currently, both the iOS and Android clients which Netflix uses are aren't canonical, standalone, library implementations. We plan to spend some time over the next few months, extracting the implementations into standalone libraries, and establishing parity with the specs and documentation you see here. Once we've broken out the canonical implementations, happy to re-engage to see if it makes sense to put them out here. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#800 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAuyewLl6Hcg0arBn_NaPr-seS0QWuuks5soSingaJpZM4JCzUL> .