GitHub Mobile and GraphQL

GitHub’s mobile applications have used GraphQL to power new features. We’ve now been able to move faster and get more done with less hassle and no over-fetching.

We were able to turn to the open source community and use Apollo for iOS and Android. By doing so, we moved at warp-speed. We also minimized ongoing engineering effort on what is a core part of our mobile applications.

GraphQL has allowed us to focus less on the tedium around networking, modeling, and API stability. It’s allowed us to focus on the things we’re really passionate about: building great experiences.

The GraphQL mindset

GraphQL has a bit of a learning curve. It requires a change in mindset for people who have worked in REST environments.

GraphQL provides interfaces, types, methods, and the associated documentation as a data structure. This paves the way for tooling to be built on top of it. This is often referred to as the schema. The schema is a representation of the available interfaces, types, and mutations that can modify them. There are no endpoints for different responses in the GraphQL world. Thus the first necessary shift in mindset is from thinking in endpoints, to thinking in types. GraphQL isn’t SQL. But, thinking about it in terms of a SQL schema can be helpful in facilitating the necessary shift in mindset. The schema is a record of the available data types, queries and mutations on the backend. External clients – like the mobile app – hold onto a reference of the schema that must be manually updated.

Moving from the REST mindset to GraphQL

Moving from the REST mindset into the GraphQL means shifting thought away from HTTP methods. You no longer think about GET and POST methods; you now only think about operations, like query and mutation. Queries are analogous to an HTTP get. They are any operation that retrieves data from the server. Mutations, on the other hand, encompass the rest of the possible HTTP operations. A mutation occurs whenever the client wants to modify data on the server. This could be a POST, PUT, DELETE, or PATCH.

Since the client defines the data it wants, and endpoints don’t exist, the response is whatever the client wants it to be – so long as it’s valid within the schema. This allows client engineers to write queries specific to the view they’re working on, rather than using bloated responses or correlating roundtrips across multiple endpoints.

Despite the shift in thought, the GraphQL mindset is actually less complex than the REST mindset. There are the available query types, available mutations, and the inputs they take. There is no more thought being given to endpoints or to response structure.

Code generation

One of the largest strengths of GraphQL on mobile, is code generation of static types for network responses. Being able to generate our network models saves us an incredible amount of time, effort, and upkeep.

In most REST-based systems, we’d have to manually define our network models and consider encoding and decoding strategies. While encoding and decoding has gotten easier over the years with both iOS’s Codable and Kotlin’s built-in serialization, it’s still a consideration that needs to be made. In addition, codable implementations require the whole model to be part of the response. Keys must be manually kept up to date with their server counterparts, and structural changes to the response are generally breaking changes to older clients.

Using Apollo and GraphQL, however, we no longer have to consider this foundational step of app development. Apollo’s tooling allows us to statically type our network responses. This leads our clients to know and trust the data they’re receiving. From there, we’re free to transform and do with them as we wish. As our backend changes, our models keep up to date with the backend changes each time we refresh our schema.

Since GraphQL API’s have field-level deprecation, we can be certain any updates to our backend models don’t break our mobile consumers.

Fragments

A fragment is a small reusable piece of GraphQL. On the GitHub mobile team, we are very heavy users of fragments. We use them to ensure data and API consistency across models. It also reduces the total number of models. A common example would be our actorFields fragment:

In the GitHub API, an Actor represents an object that can take actions – most typically a user. We re-use this fragment across large parts of our application. This allows for a very consistent model API. For example, all of our mobile timeline events have an actor or multiple actors. By using field, each of those GraphQL queries becomes shorter, and the generated models are more consistent.

By re-using fragments, this allows us to quickly prop up new queries and mutations. The more powerful aspect of using fragments is fragments are composable; we are not limited to using one fragment per type. For example, when requesting a User, we could request their actor fields as well as information related to their follows and following:

By doing this, we’re able to reduce repetition across our GraphQL queries and generate less models – the response object for SomeQuery contains two models that we’ve already previously generated. More crucially, we can now reuse and compose the fragments we’ve already defined! We can create smaller view models initialzied with type-specific fragments, and compose them into a larger view models just by composing the fragments.

Platform differences

There are noticeable differences between the iOS and Android implementations of the Apollo GraphQL library.

Both iOS and Android (via Kotlin) have introduced their own reactive primitives. Apollo’s Kotlin support is still young, but it’s working well enough for us to use in production. Combined support, however, is still on its way – it’s listed as a long-term goal in the Apollo roadmap.

Additionally, some fragments – notably those performing on interfaces – are only possible to generate on iOS. This is rarely ever a roadblock; it frequently requires more explicit adherence to the types that Apollo-GraphQL recognizes.

Ultimately, there are some platform differences, but they don’t translate into large shifts from one platform to the other. The generated code provided by Apollo is similar enough between the two languages. This means it can be used in much the same way. The Apollo team is also working on aligning and reducing differences across the Apollo Client projects – both web and mobile.

In Closing

GraphQL and Apollo’s tooling allows us to operate at a high degree of efficiency. By allowing us to abstract away many of the concerns traditionally affect mobile applications, we can focus on building features rapidly. Additionally, we get the benefit of every part of every network request becoming useful while no longer having to maintain the network responses ourselves.

#graphql #github #developer

What is GEEK

Buddha Community

On-Demand Mobile App Development Services in USA

Mobile apps are developing day-by-day and the usage of mobile apps is also increasing. There are many mobile app development company that are providing services for on-demand mobile app development services.

One of the leading mobile app development company in the USA is Nevina Infotech. It is the best known for providing on-demand app development services till now.

Our On-Demand Mobile App Development Services:-

iPhone App Development
Android App Development
iPad App Development
Game App Development
ionic App Development
Wearable App Development
Flutter App Development

#mobile app development company #mobile app development services #mobile application development services #mobile application development company #mobile app development company usa

Mobile Websites Development or Building Mobile App for Business?

What is more vital for a business, mobile website development or building a mobile app specifically designed and developed for particular businesses needs and requirements, and marketer trends. It is important to understand what are trends are going on in the market, and incorporating those trends in the digital products helps a lot in building a great relationship with our consumers.

Although there is confusion to choose which digital products would be a good fit for your business, according to my experience, I would suggest businesses to develop mobile websites, as they are more reliable and secured for their targeted audience, mobile apps are also a good medium of engaging with the targeting audience, but sometimes mobile’s notification, security guidelines irritate a lot to its users, and therefore several times this user uninstalls those mobile applications, which can be reduced if we use mobile websites, there are no such things, that can annoy users if they are on mobile websites.

Now as we know mobile websites perform well and appeal more to the targeted audience, how to find those leading mobile website development companies around us, like mobile website development Chicago, if your business is an operation in Chicago or neighbor regions, as I have been functioning as a mobile websites developer in the USA for 7 years, I am well aware of the local companies operations, and how and what approached they use in the mobile website development process.

Mobile website development is a wide topic to cover, though there are a few areas that many mobile website development firms ignore while developing these mobile websites for business, which I feel hold a major proportion in the development approach of mobile websites.

• Consistency is Navigations
• Weak Coding Foundation
• Implementing Heavy Layouts

These 3 factors I feel the most ignored aspects of mobile website development for businesses, and more mobile website development firms don’t focus on these prospects and that leads to huge loss to those businesses mobile websites.

• Consistency in Navigations

Several times because of workload and the near deadline mobile website designer ignores this vital part of building a mobile website, consistency in the navigational area are the reasons of not getting much engagement on your mobile website.

Because, if users would not be satisfied with the designs & the navigations, how they will operate and interact with a mobile website, as they don’t understand what buttons take you where.

• Weak Coding Foundation

Development of mobile websites relies on coding structure and how they have been made for the users, if a mobile web developer have did an error while building the foundation of the coding structure, that error will enlarge at the end of the product summarizing part, and it will cost huge in the overall performance of a mobile web site.

As you know how much foundation is useful in anything, if the foundation was not done rightly, your product is going to fail measurably.

• Implementing Heavy Layouts

Mobile web designers from companies or individual mobile web designers always did this simple mistake while designing a mobile website, they integrated heavy designing layouts in the simple backed developed mobile websites, and therefore their these experiments fail at a level, they would not able to resolve that issue.

furthermore, incorporating these types of layouts causes loading speed a lot, and that’s what makes this mobile website load slower, and it is not required, as mobile websites are meant to work faster than ordinary websites.

These are the major consideration a business should bear in mind while designing a mobile website for their business, as these hold much potential if your business will succeed online or not.

#mobile websites development or building mobile app for business? #mobile website development company chicago #mobile website development chicago company #mobile website development chicago

How to Compare Multiple GitHub Projects with Our GitHub Stats tool

If you have project code hosted on GitHub, chances are you might be interested in checking some numbers and stats such as stars, commits and pull requests.

You might also want to compare some similar projects in terms of the above mentioned stats, for whatever reasons that interest you.

We have the right tool for you: the simple and easy-to-use little tool called GitHub Stats.

Let’s dive right in to what we can get out of it.

Getting started

This interactive tool is really easy to use. Follow the three steps below and you’ll get what you want in real-time:

1. Head to the GitHub repo of the tool

2. Enter as many projects as you need to check on

3. Hit the Update button beside each metric

In this article we are going to compare three most popular machine learning projects for you.

#github #tools #github-statistics-react #github-stats-tool #compare-github-projects #github-projects #software-development #programming

Managing GitHub Organizations with GitHub GraphQL API

GitHub GraphQL Client
The most popular client library for consuming GraphQL services in .NET Core applications is [GraphQL.Client]. Install the library as a NuGet package in your project.

GraphQL Query: Fetch Open Issues
Upon execution, the following code will fetch all open issues created in a repository. Since the [Repository API] does not currently support fetching issues that have not been updated since a given date, we will filter the issues that have not been updated in the last 12 hours after fetching them.

GraphQL Mutation: Comment on Open Issues
The GitHub GraphQL API supports several [mutation operations] to change data on the server. We will use the [addComment] to add a comment to the issue.

#graphql #github organizations #github graphql api

List Of The Top Pittsburgh Mobile App Development Companies

https://clutch.co/app-developers/pittsburgh
Let’s look at the list of top list of the top Pittsburgh mobile app development companies which are known for providing top-notch services globally. They are great developers who provide quality services for all your needs.

#mobile app developers #mobile app development services #mobile app development #mobile app developers #mobile apps #mobile app development solutions