To add on to this, we'd love to get specific examples of things that you find challenging or that otherwise don't work well. We've found over time that these tend to fall into either A) a missing feature, B) Missing documentation, or C) a missing concept in the domain being modeled. As we've added more features and handled the edge cases, we see more of B & C than A, but of course that happens still as well.
I don't have a lot of context on OData, but from what I can tell from a quick look at the site, it seems a closer comparison would be the JSON:API spec https://jsonapi.org/. Graphiti took a great deal of influence from that spec, and was originally much more directly coupled to it. Now it's the default serialization format, but not the only one. It would probably be possible to "speak OData" as well if that was a big need.
> I'm struggling to understand the advantages and disadvantages over REST and GraphQL
The "Why Graphiti" page[1] goes into some of this, getting into some comparisons of REST, RPC, and GraphQL, as well as discussing the conventions that make some of Graphiti's approach possible.
I appreciate the effort. I think it is a bit of initial information overload having to read through tons of theory before getting to examples, which is why I skimmed through it and went to the examples. However the examples, did provide too much explanation and at the surface looks like a Query ORM via URL. This seems like a nice idea for things within a single domain, such as a master/detail view.
In my reservations example, if I wanted to get availability, pricing, and content from 3 separate domains in a microservice environment, using this paradigm, I think I still would have to create a 4th endpoint that that combines the 3 in a separate entity called VacationPackages if I wanted to keep separation of concerns.
Otherwise, it might be calling a CMS endpoint, which has an include of availability endpoint, which has a nested include of the pricing endpoint.
Hi Dlai - you'd be able to fetch it all, across all your microservices, without creating a new entity. Will try to improve our messaging, but this one might be up your alley https://www.graphiti.dev/guides/concepts/remote-resources
My understanding is that the reason Chrome has to use the iOS webkit view is because that's the only way to get JIT javascript compilation working for apps submitted to the app store. Does anyone have a sense of whether it would be possible to switch to Blink and V8 with a locally compiled and sideloaded version of the app? Would there be any benefit?
You're not allowed to provide your own web render engine at all. The JIT issue was solved a couple versions of iOS ago - embedded webviews now get JIT just like Safari.
It's my understanding that only embedded WKWebViews are allowed to enable the JIT compiler, but not UIWebViews (or in-process JavaScriptCore engines). WKWebView is an out-of-process web browser that uses IOSurface [1] to project the image into your embedding application and IPC to send messages.
So WKWebView's dynamically generated code is running safely firewalled in a separate address space controlled by Apple and not accessible to your app, while older UIWebViews run in the address space of your application, and aren't allowed to write to code pages, so their JIT compiler is disabled.
Since it's running in another process, WkWebView's JavaScriptEngine lacks the ability to expose your own Objective C classes to JavaScript so they can be called directly [2], but it does include a less efficient way of adding script message handlers that call back to Objective C code via IPC [3].
> You're not allowed to provide your own web render engine at all.
Is that true? I understand the security argument against JITs, but I don't see why it would be objectionable to run a copy of e.g. Gecko if you excluded the JS JIT component. (Of course you would never actually do that. But I'm trying to tease apart the separate arguments and see if they're actually connected.)
It seems to me that the root cause for this is all the JIT. If the JIT in iOS has to be exposed via IPC for security (as claimed in a sibling comment) it's simply not going to be a win to try to use it in combination with a separate rendering engine, if it's even possible at all.
You're not allowed to ship a interpreter that interprets code that doesn't come from insider your app.
So you can maybe ship Gecko + SpiderMonkey, as long as you only run JS that's part of your app. But if you want to run JS from a website (or indeed any code from anywhere), you're not allowed to do that on iOS.
I haven't checked whether it would be OK to ship a browser engine that doesn't support JS at all, but that's a fairly academic question anyway.
But for example, could you ship Gecko with Apple's JS engine in a way that will satisfy Apple's requirements? Of course the answer is no, but it's worth taking a second to think about why that is.
I guess what's bothering me is that there is an unstated assumption underlying this entire discussion which people never bring up: for performance reasons, the rendering engine has to be tied closely to the JS implementation. Specifically, calling over some IPC interface at every entrypoint into the JS interpreter would be a performance nightmare. This is the reason why these can't be disentangled. The connection to the interpreter is really an indirect one.
> You're not allowed to ship a interpreter that interprets code that doesn't come from insider your app.
That is not true. Many apps do this. Games have been doing this for a decade. It is not a problem to do this. Apple has never made a big deal of that. Only if you are trying to build a shadow app store.
Apple does not care. As long as you are operating in the spirit of their App Store.
You know when they care? When you start charging money for those downloads. Via an alternative payment channel. Or when you run an alternative app store from within your app.
If you download assets on demand, and some of those turn out to be executable* code, nobody cares.
* Where executable means 'interpreted' because you cannot run unsigned code. But for games that is fine, they have been doing this with JS, Lua and Python for a decade.
(You can downvote me - but this is based on a decade of experience)
They do care; Apple has shut down (or restricted) several apps over the years that have tried this. But I ultimately agree with you, it's really more about how it's presented rather than how it works under the hood. This might have a lot to do with the review process.
The subject we're talking about here would not fly under their radar.
What you're saying is that Apple is inconsistent in enforcing its officially stated policy. That may be true, but does not change what the official policy is and that they can enforce it any time they want to.
See Microsoft CodePush and React Native for a counterexample: you can certainly publish apps which download code as long as they don't dramatically alter the functionality of the app.
Before iOS 9 (or something) that JIT engine wasn't even exposed in the web view available for apps, so no matter what you did, you couldn't match the performance of Safari.
On iOS browsers like Chrome and Firefox are basically unable to compete in terms of performance, web standards or features like browser plugins. So people that use them do so just to get sync. Of course Safari Mobile is decent nowadays, but that's not the issue.
Not outdated (it's always been the same WebKit version as used by Safari), but security restrictions on iOS (specifically, third-party iOS apps can't JIT-- the OS won't let apps without a specific entitlement execute from a writable section of memory) prevented in-app web views from using the same Javascript engine as Safari.
iOS 9 eliminated that performance penalty-- it introduced a new kind of web view backed by an out-of-process renderer and JS engine, which, since it's Apple-blessed, doesn't have the JIT restriction. Third-party browsers updated to use the new framework can get the same performance as Safari.
Third-party browsers updated to use the new framework can get the same performance as Safari.
But that framework is missing various things, such as content blocking. (That goes a long way to explain why there's both "Focus" and "Firefox" on iOS)
> But that framework is missing various things, such as content blocking
Not really - SFSafariViewController uses content blockers, autofill, etc. There's also WKWebView for those that want to implement their own content blockers and autofill engines.
Curious why you'd want safari's content blockers to run inside chrome or firefox though? That's not how browser plugins work anywhere else, and it seems like if content blockers were forced in to 3rd party browsers there'd be a lot more angst over that decision.
> Curious why you'd want safari's content blockers to run inside chrome or firefox though?
Because WKWebView has such a limited API that it currently is impossible to implement content blocking.
WKWebView is both a blessing and a curse for browsers like Chrome and Firefox.
A blessing because tt works really well inside that square area where content is rendered. It is as fast as Safari, as responsive to touch gestures, supports web APIs pretty well.
A curse because the API that it exposes is completely lacking. No way to intercept network requests, no way to interact with the DOM, no way to interact with JavaScript, no way to customize it fully, no way to do proper session store/restore, no way to interact with its internal caches, no way to set the cookie policy, no way to customize the context menus that it exposes, no way to handle errors better, no way to set headers on requests, no way to use content filters ..
I can go on for a while. You can look at the Chrome and Firefox source code to understand the crazy workaround both browsers had to do to get some pretty basic functionality.
Search for WKWebView on https://bugz.webkit.org to see what people have been asking for, for the past three years.
Not sure why this is downvoted because gcp is correct.
Apple has decided that Content Blocking is a Safari only feature. Apple has made the decision to not expose the private APIs in WKWebView that would allow browsers like Chrome and Firefox to use the same speedy content blocking.
The old WebView, UIWebView, also does not support content blocking. But since it runs completely in the same process as your app, you can replace the HTTP handling with your own and patch content blocking on top of that.
That is what Firefox Focus and Brave do for example. It works, but it is far from ideal. Also, it is likely an API on the way to be deprecated.
> Not really - SFSafariViewController uses content blockers, autofill, etc.
SFSafariViewController is useles for apps like Chrome and Firefox. It is an embedded Safari controller. Not an embedded generic webview controller.
SFSafariViewController has zero API. All it can do is display a webpage. Applications that use it have zero ability to even modify the UI.
That is intentional. It is supposed to be a Safari view. And for security reasons that is probabl good, otherwise it would be a gateway to your browsing data.
SFSafariViewController essentially IS safari. It isn't appropriate for a third-party browser.
While it is technically possible to use content blockers in WKWebView, it can only be done via private APIs, and Apple capriciously bans apps from their appstore that use private APIs.
No. You can't map executable pages in the sandbox. JITs (such as LuaJIT) only work while the debugger is attached (i.e., you open the app by clicking "run" in Xcode).
Opera Mini bypasses this restriction with doing Server Rendering. I wonder why Apple is ok with them (because it'a a big security risk to server render HTTPS IMHO).
And regarding your quesiton: I'm sure you cannot replace their webkit usage with one switch to Blink... I'm sure the iOS internal webview is deeply integrated/
While it wasn't explicit in the article, it seems the focus here was much more on poor and working class communities with high performers. Students from those places able to get into top tier institutions are unlikely to be paying much if anything for their tuition.
The general idea is to test and develop on the same image that will go to prod. Environment-specific configuration should generally be injected at container runtime.
Hi. I know Distelli was originally less targeted and could deploy to bare metal, snowflake VMs, k8s, etc. Is this latest version a narrowing of focus or is all that just less promoted now?
We still support the VM, bare metal use cases. We've just created a new landing page around k8s because its our latest offering and its on our list to add additional pages around our existing VM use cases.
Sorry we're scaling up under the load from HN traffic. Email me at rsingh@distelli.com and I'll be happy to help you with pricing or any other questions you might have.
No problem ... I just thought you'd want to know. We're in the beginning stages of container orchestration and have to keep parts of our pipeline and server infrastructure on premises. I'll email you if we have portions that can realistically be put on the cloud.
Not likely to become a law either. Many congresspersons have an excellent backup plan in becoming a well-connected lobbyist if they are ever voted out of office. They are not likely to vote that away from themselves.
