This half-day tutorial introduces Protocol Buffers, gRPC, and the open source tools that Google uses to publish and support some of the world's biggest APIs. We'll show how the Protocol Buffer language allows APIs to be described, reviewed, and implemented in a programming-language independent way, how gRPC enables high-performance streaming APIs, and how \ a few simple conventions can enable related tools to serve robust REST APIs and generate production-quality client libraries in seven popular programming languages. This is API publishing the Google way, but large teams aren't required. With shared open-source tooling, even the smallest developer can build scalable, usable APIs that delight.
https://apistrat18.sched.com/event/FTR3/usable-apis-at-scale-with-protocol-buffers-and-grpc-tim-burks-andrew-gunsch-google
Implementing OpenAPI and GraphQL services with gRPCTim Burks
Behind every API there's code. REST and GraphQL are powerful interface abstractions but are not so great for writing code (we’re still looking for the programming language where every command is a GET, POST, PUT, or DELETE). When programmers work, they are usually making function calls, and an RPC framework like gRPC allows those functions to be written in a mixture of languages and distributed among many servers. This means that gRPC can be a great way to implement REST and GraphQL APIs at scale. We’ll share open source projects from Google that can be used to implement OpenAPI and GraphQL services with gRPC and give you hands-on experience with both.
Presented at the 2019 API Specifications Conference.
https://asc2019.sched.com/event/T6u9/workshop-implementing-openapi-and-graphql-services-with-grpc-tim-burks-google
Did you know that the best way to build a REST API is with an RPC framework? We’ll look at how Google and other large API producers use gRPC to build REST APIs that users love because they follow the OpenAPI Specification and that producers love because gRPC gives them power and scaling.
Enforcing API Design Rules for High Quality Code GenerationTim Burks
[Co-presented with Mike Kistler, Architect for SDK Generation for the Watson Client Libraries]
The OpenAPI Specification is emerging as the leading standard for describing REST APIs. A key factor in the popularity of OpenAPI is the broad array of open source tools that it enables that create, manipulate, and publish documentation and code from OpenAPI descriptions. In this talk, we describe a configurable and extensible open source linter for OpenAPI that we are using to solve API code generation problems at IBM and Google. Our linter is based on Gnostic, an open source framework for working with API descriptions that was developed at Google and is available on GitHub.
OpenAPI itself is language-agnostic and is being used to generate code in a large set of popular programming languages. This generated code includes both server-side "stubs" and client libraries that are sometimes called software development kits (SDKs). IBM has begun to employ code generation for the Watson Developer Cloud SDKs and other companies are doing similar things, including Google, which generates client libraries from Google-specific API description formats. These teams have found that the quality of SDKs generated from API descriptions depends heavily on the quality of the descriptions. This goes far beyond mere syntactic compliance with a specification -- it involves proper API design, naming, and adherence to organization-wide design patterns. To address this, many companies have created API design guides. Some companies, such as Google and Microsoft, have published their API design guides externally, while others like IBM have kept theirs as internal documents. But to this point, verifying compliance with an API design guide has largely been a manual task. What is needed, we believe, is a configurable and extensible linter to check OpenAPI descriptions for conformance with rules derived from API design guides.
CocoaConf: The Language of Mobile Software is APIsTim Burks
We’re all excited about using the same language to write our mobile apps and cloud services, but as we do, we’ll still need to work with a few things that aren’t written with Swift. Fortunately, there are some great patterns that we can use for doing that. In this session we’ll talk about two technologies that you can use to make your app speak with APIs written in any language: OpenAPI and Protocol Buffers, and then we’ll see how to use them from clients and servers that are written in Swift.
Presented Friday November 4, 2016 in San Jose.
Running gRPC Services for Serving Legacy API on KubernetesSungwon Lee
gRPC is best suited for microservice communication. gRPC is fast, clear and powerful. It is an excellent alternative to address the verbose client problem when architecting a microservice infrastructure.
But the legacy environment is always a big hurdle for changes. You must support existing clients that only understand RESTful HTTP API. In other cases, you need to provide RESTful APIs to the outside world. This session suggests solutions to resolve these problems.
The session covers:
- Why the team chose gRPC as the inter-service communication protocol while moving from a monolith to microservices and the challenges they faced.
- How they leveraged Istio to support RESTful APIs using gRPC servers without additional development.
- How they set up CI/CD to deliver API changes (including legacy API) using Helm and Spinnaker.
- What they have learned through it and future improvements.
gRPC는 마이크로서비스 커뮤니케이션에 가장 적합합니다. gRPC는 빠르고 명확하고 강력합니다. 이는 마이크로서비스 인프라를 설계할 때 복잡한 클라이언트의 문제를 해결하는데 있어 훌륭한 대안입니다.
하지만 기존 레거시 환경은 항상 변화의 큰 장애물입니다. RESTful HTTP API만을 이해하는 기존 클라이언트를 지원해야 합니다. 다른 경우, RESTful API를 외부에 제공해야 합니다. 본 세션에서는 이러한 문제를 해결할 솔루션을 제안합니다.
이 세션에서 다루는 내용:
- 팀이 모놀리스에서 마이크로서비스로 전환하면서 서비스 간 커뮤니케이션 프로토콜로 gPRC를 선택한 이유 및 직면했던 난관들
- 추가 개발 없이 gRPC 서버를 이용해 RESTful API를 지원하기 위해 이스티오를 활용한 방법
- 헬름 및 스피네이커를 사용해 API 변경 사항 (레거시 API 포함)을 전달하기 위해 CI/CD를 설정하는 방법
- 이를 통해 배운 것과 앞으로 개선할 점
GraphQL - A query language to empower your API consumers (NDC Sydney 2017)Rob Crowley
The shift to microservices, cloud native and rich web apps have made it challenging to deliver compelling API experiences. REST, as specified in Roy Fielding’s seminal dissertation, has become the architectural pattern of choice for APIs and when applied correctly allows for clients and servers to evolve in a loosely coupled manner. There are areas however where REST can deliver less than ideal client experiences. Often many HTTP requests are required to render a single view.
While this may be a minor concern for a web app running on a WAN with low latency and high bandwidth, it can yield poor client experiences for mobile clients in particular. GraphQL is Facebook’s response to this challenge and it is quickly proving itself as an exciting alternative to RESTful APIs for a wide range of contexts. GraphQL is a query language that provides a clean and simple syntax for consumers to interrogate your APIs. These queries are strongly types, hierarchical and enable clients to retrieve only the data they need.
In this session, we will take a hands-on look at GraphQL and see how it can be used to build APIs that are a joy to use.
Implementing OpenAPI and GraphQL services with gRPCTim Burks
Behind every API there's code. REST and GraphQL are powerful interface abstractions but are not so great for writing code (we’re still looking for the programming language where every command is a GET, POST, PUT, or DELETE). When programmers work, they are usually making function calls, and an RPC framework like gRPC allows those functions to be written in a mixture of languages and distributed among many servers. This means that gRPC can be a great way to implement REST and GraphQL APIs at scale. We’ll share open source projects from Google that can be used to implement OpenAPI and GraphQL services with gRPC and give you hands-on experience with both.
Presented at the 2019 API Specifications Conference.
https://asc2019.sched.com/event/T6u9/workshop-implementing-openapi-and-graphql-services-with-grpc-tim-burks-google
Did you know that the best way to build a REST API is with an RPC framework? We’ll look at how Google and other large API producers use gRPC to build REST APIs that users love because they follow the OpenAPI Specification and that producers love because gRPC gives them power and scaling.
Enforcing API Design Rules for High Quality Code GenerationTim Burks
[Co-presented with Mike Kistler, Architect for SDK Generation for the Watson Client Libraries]
The OpenAPI Specification is emerging as the leading standard for describing REST APIs. A key factor in the popularity of OpenAPI is the broad array of open source tools that it enables that create, manipulate, and publish documentation and code from OpenAPI descriptions. In this talk, we describe a configurable and extensible open source linter for OpenAPI that we are using to solve API code generation problems at IBM and Google. Our linter is based on Gnostic, an open source framework for working with API descriptions that was developed at Google and is available on GitHub.
OpenAPI itself is language-agnostic and is being used to generate code in a large set of popular programming languages. This generated code includes both server-side "stubs" and client libraries that are sometimes called software development kits (SDKs). IBM has begun to employ code generation for the Watson Developer Cloud SDKs and other companies are doing similar things, including Google, which generates client libraries from Google-specific API description formats. These teams have found that the quality of SDKs generated from API descriptions depends heavily on the quality of the descriptions. This goes far beyond mere syntactic compliance with a specification -- it involves proper API design, naming, and adherence to organization-wide design patterns. To address this, many companies have created API design guides. Some companies, such as Google and Microsoft, have published their API design guides externally, while others like IBM have kept theirs as internal documents. But to this point, verifying compliance with an API design guide has largely been a manual task. What is needed, we believe, is a configurable and extensible linter to check OpenAPI descriptions for conformance with rules derived from API design guides.
CocoaConf: The Language of Mobile Software is APIsTim Burks
We’re all excited about using the same language to write our mobile apps and cloud services, but as we do, we’ll still need to work with a few things that aren’t written with Swift. Fortunately, there are some great patterns that we can use for doing that. In this session we’ll talk about two technologies that you can use to make your app speak with APIs written in any language: OpenAPI and Protocol Buffers, and then we’ll see how to use them from clients and servers that are written in Swift.
Presented Friday November 4, 2016 in San Jose.
Running gRPC Services for Serving Legacy API on KubernetesSungwon Lee
gRPC is best suited for microservice communication. gRPC is fast, clear and powerful. It is an excellent alternative to address the verbose client problem when architecting a microservice infrastructure.
But the legacy environment is always a big hurdle for changes. You must support existing clients that only understand RESTful HTTP API. In other cases, you need to provide RESTful APIs to the outside world. This session suggests solutions to resolve these problems.
The session covers:
- Why the team chose gRPC as the inter-service communication protocol while moving from a monolith to microservices and the challenges they faced.
- How they leveraged Istio to support RESTful APIs using gRPC servers without additional development.
- How they set up CI/CD to deliver API changes (including legacy API) using Helm and Spinnaker.
- What they have learned through it and future improvements.
gRPC는 마이크로서비스 커뮤니케이션에 가장 적합합니다. gRPC는 빠르고 명확하고 강력합니다. 이는 마이크로서비스 인프라를 설계할 때 복잡한 클라이언트의 문제를 해결하는데 있어 훌륭한 대안입니다.
하지만 기존 레거시 환경은 항상 변화의 큰 장애물입니다. RESTful HTTP API만을 이해하는 기존 클라이언트를 지원해야 합니다. 다른 경우, RESTful API를 외부에 제공해야 합니다. 본 세션에서는 이러한 문제를 해결할 솔루션을 제안합니다.
이 세션에서 다루는 내용:
- 팀이 모놀리스에서 마이크로서비스로 전환하면서 서비스 간 커뮤니케이션 프로토콜로 gPRC를 선택한 이유 및 직면했던 난관들
- 추가 개발 없이 gRPC 서버를 이용해 RESTful API를 지원하기 위해 이스티오를 활용한 방법
- 헬름 및 스피네이커를 사용해 API 변경 사항 (레거시 API 포함)을 전달하기 위해 CI/CD를 설정하는 방법
- 이를 통해 배운 것과 앞으로 개선할 점
GraphQL - A query language to empower your API consumers (NDC Sydney 2017)Rob Crowley
The shift to microservices, cloud native and rich web apps have made it challenging to deliver compelling API experiences. REST, as specified in Roy Fielding’s seminal dissertation, has become the architectural pattern of choice for APIs and when applied correctly allows for clients and servers to evolve in a loosely coupled manner. There are areas however where REST can deliver less than ideal client experiences. Often many HTTP requests are required to render a single view.
While this may be a minor concern for a web app running on a WAN with low latency and high bandwidth, it can yield poor client experiences for mobile clients in particular. GraphQL is Facebook’s response to this challenge and it is quickly proving itself as an exciting alternative to RESTful APIs for a wide range of contexts. GraphQL is a query language that provides a clean and simple syntax for consumers to interrogate your APIs. These queries are strongly types, hierarchical and enable clients to retrieve only the data they need.
In this session, we will take a hands-on look at GraphQL and see how it can be used to build APIs that are a joy to use.
REST API vs gRPC, which one should you use in breaking a monolith [Dev conf 2...Vladimir Dejanovic
You heard of "new thing" called gRPC and promises that it will solve all issues for you, so now you are not sure if you should use it for breaking up your monolith to Microservices. If it is good for Google it should be good for you also right?
On the other hand, you have been using REST API's for some time now, at least as a consumer, so maybe this would be better approach in Microservices waters, or would it?
Which one to chose and which one will fit your use case better?
Join me in this talk were I will try to explain both approaches, good and bad. I will give some points and tips, which will help you in understanding better which one will be better for you. By doing this I will also share some best practices for both approaches
Code Example: https://github.com/vladimir-dejanovic/grpc-bank-example
You heard of "new thing" called gRPC and promises that it will solve all issues for you, so now you are not sure if you should use it for breaking up your monolith to Microservices.
On the other hand, you have been using REST API's for some time now, at least as a consumer, so maybe this would be better approach in Microservices waters, or would it?
Which one to chose and which one will fit your use case better?
Join me in this talk were I will try to explain both approaches, good and bad. I will give some points and tips, which will help you in understanding better which one will be better for you. By doing this I will also share some best practices for both approaches
REST API vs gRPC, which one should you use in breaking a monolith [Kdg.net 2018]Vladimir Dejanovic
You heard of "new thing" called gRPC and promises that it will solve all issues for you, so now you are not sure if you should use it for breaking up your monolith to Microservices. If it is good for Google it should be good for you also right?
On the other hand, you have been using REST API's for some time now, at least as a consumer, so maybe this would be better approach in Microservices waters, or would it?
Which one to chose and which one will fit your use case better?
Join me in this talk were I will try to explain both approaches, good and bad. I will give some points and tips, which will help you in understanding better which one will be better for you. By doing this I will also share some best practices for both approaches
Connecting the Dots: Kong for GraphQL EndpointsJulien Bataillé
GraphQL is a popular alternative to REST for front-end applications as it offers flexibility and developer-friendly tooling. In this talk, we will look into the differences between REST and GraphQL, how GraphQL API Management presents a new set of challenges, and finally, how we can address those challenges by leveraging Kong extensibility.
This presentation is an overview of the API design and management solutions suitable for Cloud Native Environments. This main focus lies on synchronous API design and micro services.
From on premises monolith to cloud microservicesAlbert Lombarte
Presentation from Devops Barcelona conference on June 2019.
Step by step process to migrate from a monolith to several microservices in the cloud.
See with transitions at https://docs.google.com/presentation/d/10PvqjwDwBv96Ga2k0ZLrfi83NrQQnGQyLPKn0XsYC40/edit#slide=id.g585eb34422_0_592
Doctrine ORM with eZ Platform REST API and GraphQLJani Tarvainen
The eZ Platform Enterprise Content Management System (CMS) can accommodate additional data sources in addition to it's standard content repository. Written in PHP on the Symfony full stack framework developers can use relational databases, hybrid SQL engines like PostgreSQL or MySQL or NoSQL stores like MongoDB. This presentation shows some hands on examples with the Doctrine ORM, also integrating with the GraphQL protocol as well as the built in REST Framework of eZ Platform.
As presented at DevDuck #3 - JavaScript meetup for developers (www.devduck.pl)
-----
Get know more about GraphQL
-----
Looking for a company to build you an electron desktop app? www.brainhub.eu
Building scalable and language independent java services using apache thriftTalentica Software
This presentation is about the key challenges of cross language interactions and how they can be overcome. We discuss the Apache Thrift as a solution and understand its principle of Operation with code snippets and examples.
"Different software evolutions from Start till Release in PHP product" Oleksa...Fwdays
Ця розповідь розкриє підходи для вирішення багатьох проблем в PHP проєктах через: None-Breaking change development підхід, cross-stack контракти, Trunk Based development, еволюція з Polyrepo до Monorepo з компонентами на різних технологіях, Boilerplat’и компонентів, різні Architecture View, Continuous Testing & Quality, Infrastructure View, Infrastructure as a code як основний інструмент.
apidays LIVE Helsinki - Implementing OpenAPI and GraphQL Services with gRPC b...apidays
apidays LIVE Helsinki - APIs, Platforms, And Ecosystems - Transforming Industries And Experiences
Implementing OpenAPI and GraphQL Services with gRPC
Tim Burks, Software Engineer at Google
REST API vs gRPC, which one should you use in breaking a monolith [Dev conf 2...Vladimir Dejanovic
You heard of "new thing" called gRPC and promises that it will solve all issues for you, so now you are not sure if you should use it for breaking up your monolith to Microservices. If it is good for Google it should be good for you also right?
On the other hand, you have been using REST API's for some time now, at least as a consumer, so maybe this would be better approach in Microservices waters, or would it?
Which one to chose and which one will fit your use case better?
Join me in this talk were I will try to explain both approaches, good and bad. I will give some points and tips, which will help you in understanding better which one will be better for you. By doing this I will also share some best practices for both approaches
Code Example: https://github.com/vladimir-dejanovic/grpc-bank-example
You heard of "new thing" called gRPC and promises that it will solve all issues for you, so now you are not sure if you should use it for breaking up your monolith to Microservices.
On the other hand, you have been using REST API's for some time now, at least as a consumer, so maybe this would be better approach in Microservices waters, or would it?
Which one to chose and which one will fit your use case better?
Join me in this talk were I will try to explain both approaches, good and bad. I will give some points and tips, which will help you in understanding better which one will be better for you. By doing this I will also share some best practices for both approaches
REST API vs gRPC, which one should you use in breaking a monolith [Kdg.net 2018]Vladimir Dejanovic
You heard of "new thing" called gRPC and promises that it will solve all issues for you, so now you are not sure if you should use it for breaking up your monolith to Microservices. If it is good for Google it should be good for you also right?
On the other hand, you have been using REST API's for some time now, at least as a consumer, so maybe this would be better approach in Microservices waters, or would it?
Which one to chose and which one will fit your use case better?
Join me in this talk were I will try to explain both approaches, good and bad. I will give some points and tips, which will help you in understanding better which one will be better for you. By doing this I will also share some best practices for both approaches
Connecting the Dots: Kong for GraphQL EndpointsJulien Bataillé
GraphQL is a popular alternative to REST for front-end applications as it offers flexibility and developer-friendly tooling. In this talk, we will look into the differences between REST and GraphQL, how GraphQL API Management presents a new set of challenges, and finally, how we can address those challenges by leveraging Kong extensibility.
This presentation is an overview of the API design and management solutions suitable for Cloud Native Environments. This main focus lies on synchronous API design and micro services.
From on premises monolith to cloud microservicesAlbert Lombarte
Presentation from Devops Barcelona conference on June 2019.
Step by step process to migrate from a monolith to several microservices in the cloud.
See with transitions at https://docs.google.com/presentation/d/10PvqjwDwBv96Ga2k0ZLrfi83NrQQnGQyLPKn0XsYC40/edit#slide=id.g585eb34422_0_592
Doctrine ORM with eZ Platform REST API and GraphQLJani Tarvainen
The eZ Platform Enterprise Content Management System (CMS) can accommodate additional data sources in addition to it's standard content repository. Written in PHP on the Symfony full stack framework developers can use relational databases, hybrid SQL engines like PostgreSQL or MySQL or NoSQL stores like MongoDB. This presentation shows some hands on examples with the Doctrine ORM, also integrating with the GraphQL protocol as well as the built in REST Framework of eZ Platform.
As presented at DevDuck #3 - JavaScript meetup for developers (www.devduck.pl)
-----
Get know more about GraphQL
-----
Looking for a company to build you an electron desktop app? www.brainhub.eu
Building scalable and language independent java services using apache thriftTalentica Software
This presentation is about the key challenges of cross language interactions and how they can be overcome. We discuss the Apache Thrift as a solution and understand its principle of Operation with code snippets and examples.
"Different software evolutions from Start till Release in PHP product" Oleksa...Fwdays
Ця розповідь розкриє підходи для вирішення багатьох проблем в PHP проєктах через: None-Breaking change development підхід, cross-stack контракти, Trunk Based development, еволюція з Polyrepo до Monorepo з компонентами на різних технологіях, Boilerplat’и компонентів, різні Architecture View, Continuous Testing & Quality, Infrastructure View, Infrastructure as a code як основний інструмент.
apidays LIVE Helsinki - Implementing OpenAPI and GraphQL Services with gRPC b...apidays
apidays LIVE Helsinki - APIs, Platforms, And Ecosystems - Transforming Industries And Experiences
Implementing OpenAPI and GraphQL Services with gRPC
Tim Burks, Software Engineer at Google
OpenAPI es un estándar emergente para crear, administrar y consumir API REST. Conocido anteriormente como Swagger, en el último año ha sido adoptado por la Linux Foundation y obtuvo el apoyo de compañías como Google, Microsoft, IBM, Paypal, etc. para convertirse en un estándar de facto para las API.
En esta charla, contaremos con Pedro J. Molina (@pmolinam) como ponente, y veremos 3 casos de usos para aplicar OpenAPI para mejorar y acelerar nuestros desarrollos para crear APIs compatibles con OpenAPI:
- Legacy APIs,
- Contract first y,
- Server driven
GraphQL can be one of the best ways to make your product development more fun and productive. In this presentation I talk about how GraphQL makes your life simpler, and how to write and deploy a GraphQL API with Apollo Server 2.0 and serverless deployment via Netlify Functions.
Introduction to Cloud Computing with Google Cloudwesley chun
This is a 20-30 minute technical talk introducing developers to cloud computing including an overview of Google Cloud computing products. There is a special focus on serverless tools as a convenient way for developers to run code. The talk ends with several inspirational apps showcasing what is possible with Google Cloud tools meant to plant a seed as to consider what is possible.
Have you ever left out a comma in your payload calling an API on the command line? Have you cURL’d a REST API only to realize you forgot that crucial query parameter? If only the command line could take advantage of some structured description of the API model…
APIs can be challenging to understand and consume from the command line, a utility most developers use daily. In this session we will look at an approach to generating intuitive command line utilities for gRPC APIs.
This is a 15-20 minute tech talk designed for those who wish to use Google APIs, but don't know how to get started quickly. This session introduces developers to two distinct ways of accessing our APIs, the standard HTTP-based REST APIs or Google Apps Script, a customized JS environment which provides Google API access via objects. It concludes with some inspirational app ideas of what you can build using Google Cloud APIs (covering both GCP & G Suite).
Why we chose Argo Workflow to scale DevOps at InVisionNebulaworks
As the DevOps team grows in size and start to form a multi DevOps team structure, it starts to experience growing pains such as working in silos, decreased velocity, or lack of collaboration. The solution is to standardize tools for automation and provide the building blocks of commonly used patterns readily available. This is where workflows come into play. Adopting Workflows provides a common scalable platform for DevOps engineers to automate, trigger, and execute repetitive tasks and therefore leads to increased efficiency and innovation.
Choreo Community Call 1: How to Create a Service in Choreo!
Agenda:
1. Introduction to Choreo
2. Introduction to Service Components
- What are Service components and its use cases
- Capabilities
3. Demo
- Deploy a Todo list web application
Watch the video at : https://youtube.com/live/FX06RgpNUB4
Spend some time working with OpenAPI and gRPC and you’ll notice that these two technologies have a lot in common. Both are open source efforts, both describe APIs, and both promise better experiences for API producers and consumers. So why do we need both? If we do, what value does each provide? What can each project learn from the other? We’ll bring the two together for a side-by-side comparison and pose answers to these and other questions about two API methodologies that will do much to influence the future of networked APIs.
LF_APIStrat17_OpenAPI and gRPC Side-by-SideLF_APIStrat
Spend some time working with OpenAPI and gRPC and you’ll notice that these two technologies have a lot in common. Both are open source efforts, both describe APIs, and both promise better experiences for API producers and consumers. So why do we need both? If we do, what value does each provide? What can each project learn from the other? We’ll bring the two together for a side-by-side comparison and pose answers to these and other questions about two API methodologies that will do much to influence the future of networked APIs.
How can we help API platform teams ensure that their organizations make and use secure, reliable, and easy-to-use APIs?
This is a question that we’ve been asking on my team at Google, and in September I shared some conclusions that we were drawing from research and interviews of teams that were working to improve the quality and security of the APIs in their large organizations. The presentation, Governing APIs at Scale, walked through twelve requirements for an API governance platform, i.e. the software tools that these teams would use to be more productive.
What I learned about APIs in my first year at GoogleTim Burks
Tim Burks spent a decade building Electronic Design Automation systems and another building mobile apps. Now he's focused on the thing that holds them all together: APIs. In 2016 he joined Google where he works on open source software that helps developers use gRPC and OpenAPI.
I've been working in the iOS community since 2008, and I've seen many people come to Objective-C.
I've also seen many of them complain about it.
I called this talk "Interpreting Objective-C" because I hope it will help you understand Objective-C a little better, and especially realize that when people describe Objective-C in terms of brackets and colons, they're missing its true nature.
Climate Science Flows: Enabling Petabyte-Scale Climate Analysis with the Eart...Globus
The Earth System Grid Federation (ESGF) is a global network of data servers that archives and distributes the planet’s largest collection of Earth system model output for thousands of climate and environmental scientists worldwide. Many of these petabyte-scale data archives are located in proximity to large high-performance computing (HPC) or cloud computing resources, but the primary workflow for data users consists of transferring data, and applying computations on a different system. As a part of the ESGF 2.0 US project (funded by the United States Department of Energy Office of Science), we developed pre-defined data workflows, which can be run on-demand, capable of applying many data reduction and data analysis to the large ESGF data archives, transferring only the resultant analysis (ex. visualizations, smaller data files). In this talk, we will showcase a few of these workflows, highlighting how Globus Flows can be used for petabyte-scale climate analysis.
SOCRadar Research Team: Latest Activities of IntelBrokerSOCRadar
The European Union Agency for Law Enforcement Cooperation (Europol) has suffered an alleged data breach after a notorious threat actor claimed to have exfiltrated data from its systems. Infamous data leaker IntelBroker posted on the even more infamous BreachForums hacking forum, saying that Europol suffered a data breach this month.
The alleged breach affected Europol agencies CCSE, EC3, Europol Platform for Experts, Law Enforcement Forum, and SIRIUS. Infiltration of these entities can disrupt ongoing investigations and compromise sensitive intelligence shared among international law enforcement agencies.
However, this is neither the first nor the last activity of IntekBroker. We have compiled for you what happened in the last few days. To track such hacker activities on dark web sources like hacker forums, private Telegram channels, and other hidden platforms where cyber threats often originate, you can check SOCRadar’s Dark Web News.
Stay Informed on Threat Actors’ Activity on the Dark Web with SOCRadar!
Your Digital Assistant.
Making complex approach simple. Straightforward process saves time. No more waiting to connect with people that matter to you. Safety first is not a cliché - Securely protect information in cloud storage to prevent any third party from accessing data.
Would you rather make your visitors feel burdened by making them wait? Or choose VizMan for a stress-free experience? VizMan is an automated visitor management system that works for any industries not limited to factories, societies, government institutes, and warehouses. A new age contactless way of logging information of visitors, employees, packages, and vehicles. VizMan is a digital logbook so it deters unnecessary use of paper or space since there is no requirement of bundles of registers that is left to collect dust in a corner of a room. Visitor’s essential details, helps in scheduling meetings for visitors and employees, and assists in supervising the attendance of the employees. With VizMan, visitors don’t need to wait for hours in long queues. VizMan handles visitors with the value they deserve because we know time is important to you.
Feasible Features
One Subscription, Four Modules – Admin, Employee, Receptionist, and Gatekeeper ensures confidentiality and prevents data from being manipulated
User Friendly – can be easily used on Android, iOS, and Web Interface
Multiple Accessibility – Log in through any device from any place at any time
One app for all industries – a Visitor Management System that works for any organisation.
Stress-free Sign-up
Visitor is registered and checked-in by the Receptionist
Host gets a notification, where they opt to Approve the meeting
Host notifies the Receptionist of the end of the meeting
Visitor is checked-out by the Receptionist
Host enters notes and remarks of the meeting
Customizable Components
Scheduling Meetings – Host can invite visitors for meetings and also approve, reject and reschedule meetings
Single/Bulk invites – Invitations can be sent individually to a visitor or collectively to many visitors
VIP Visitors – Additional security of data for VIP visitors to avoid misuse of information
Courier Management – Keeps a check on deliveries like commodities being delivered in and out of establishments
Alerts & Notifications – Get notified on SMS, email, and application
Parking Management – Manage availability of parking space
Individual log-in – Every user has their own log-in id
Visitor/Meeting Analytics – Evaluate notes and remarks of the meeting stored in the system
Visitor Management System is a secure and user friendly database manager that records, filters, tracks the visitors to your organization.
"Secure Your Premises with VizMan (VMS) – Get It Now"
Cyaniclab : Software Development Agency Portfolio.pdfCyanic lab
CyanicLab, an offshore custom software development company based in Sweden,India, Finland, is your go-to partner for startup development and innovative web design solutions. Our expert team specializes in crafting cutting-edge software tailored to meet the unique needs of startups and established enterprises alike. From conceptualization to execution, we offer comprehensive services including web and mobile app development, UI/UX design, and ongoing software maintenance. Ready to elevate your business? Contact CyanicLab today and let us propel your vision to success with our top-notch IT solutions.
First Steps with Globus Compute Multi-User EndpointsGlobus
In this presentation we will share our experiences around getting started with the Globus Compute multi-user endpoint. Working with the Pharmacology group at the University of Auckland, we have previously written an application using Globus Compute that can offload computationally expensive steps in the researcher's workflows, which they wish to manage from their familiar Windows environments, onto the NeSI (New Zealand eScience Infrastructure) cluster. Some of the challenges we have encountered were that each researcher had to set up and manage their own single-user globus compute endpoint and that the workloads had varying resource requirements (CPUs, memory and wall time) between different runs. We hope that the multi-user endpoint will help to address these challenges and share an update on our progress here.
Check out the webinar slides to learn more about how XfilesPro transforms Salesforce document management by leveraging its world-class applications. For more details, please connect with sales@xfilespro.com
If you want to watch the on-demand webinar, please click here: https://www.xfilespro.com/webinars/salesforce-document-management-2-0-smarter-faster-better/
Globus Compute wth IRI Workflows - GlobusWorld 2024Globus
As part of the DOE Integrated Research Infrastructure (IRI) program, NERSC at Lawrence Berkeley National Lab and ALCF at Argonne National Lab are working closely with General Atomics on accelerating the computing requirements of the DIII-D experiment. As part of the work the team is investigating ways to speedup the time to solution for many different parts of the DIII-D workflow including how they run jobs on HPC systems. One of these routes is looking at Globus Compute as a way to replace the current method for managing tasks and we describe a brief proof of concept showing how Globus Compute could help to schedule jobs and be a tool to connect compute at different facilities.
Enhancing Research Orchestration Capabilities at ORNL.pdfGlobus
Cross-facility research orchestration comes with ever-changing constraints regarding the availability and suitability of various compute and data resources. In short, a flexible data and processing fabric is needed to enable the dynamic redirection of data and compute tasks throughout the lifecycle of an experiment. In this talk, we illustrate how we easily leveraged Globus services to instrument the ACE research testbed at the Oak Ridge Leadership Computing Facility with flexible data and task orchestration capabilities.
Into the Box Keynote Day 2: Unveiling amazing updates and announcements for modern CFML developers! Get ready for exciting releases and updates on Ortus tools and products. Stay tuned for cutting-edge innovations designed to boost your productivity.
In software engineering, the right architecture is essential for robust, scalable platforms. Wix has undergone a pivotal shift from event sourcing to a CRUD-based model for its microservices. This talk will chart the course of this pivotal journey.
Event sourcing, which records state changes as immutable events, provided robust auditing and "time travel" debugging for Wix Stores' microservices. Despite its benefits, the complexity it introduced in state management slowed development. Wix responded by adopting a simpler, unified CRUD model. This talk will explore the challenges of event sourcing and the advantages of Wix's new "CRUD on steroids" approach, which streamlines API integration and domain event management while preserving data integrity and system resilience.
Participants will gain valuable insights into Wix's strategies for ensuring atomicity in database updates and event production, as well as caching, materialization, and performance optimization techniques within a distributed system.
Join us to discover how Wix has mastered the art of balancing simplicity and extensibility, and learn how the re-adoption of the modest CRUD has turbocharged their development velocity, resilience, and scalability in a high-growth environment.
Listen to the keynote address and hear about the latest developments from Rachana Ananthakrishnan and Ian Foster who review the updates to the Globus Platform and Service, and the relevance of Globus to the scientific community as an automation platform to accelerate scientific discovery.
OpenFOAM solver for Helmholtz equation, helmholtzFoam / helmholtzBubbleFoamtakuyayamamoto1800
In this slide, we show the simulation example and the way to compile this solver.
In this solver, the Helmholtz equation can be solved by helmholtzFoam. Also, the Helmholtz equation with uniformly dispersed bubbles can be simulated by helmholtzBubbleFoam.
Developing Distributed High-performance Computing Capabilities of an Open Sci...Globus
COVID-19 had an unprecedented impact on scientific collaboration. The pandemic and its broad response from the scientific community has forged new relationships among public health practitioners, mathematical modelers, and scientific computing specialists, while revealing critical gaps in exploiting advanced computing systems to support urgent decision making. Informed by our team’s work in applying high-performance computing in support of public health decision makers during the COVID-19 pandemic, we present how Globus technologies are enabling the development of an open science platform for robust epidemic analysis, with the goal of collaborative, secure, distributed, on-demand, and fast time-to-solution analyses to support public health.
Providing Globus Services to Users of JASMIN for Environmental Data AnalysisGlobus
JASMIN is the UK’s high-performance data analysis platform for environmental science, operated by STFC on behalf of the UK Natural Environment Research Council (NERC). In addition to its role in hosting the CEDA Archive (NERC’s long-term repository for climate, atmospheric science & Earth observation data in the UK), JASMIN provides a collaborative platform to a community of around 2,000 scientists in the UK and beyond, providing nearly 400 environmental science projects with working space, compute resources and tools to facilitate their work. High-performance data transfer into and out of JASMIN has always been a key feature, with many scientists bringing model outputs from supercomputers elsewhere in the UK, to analyse against observational or other model data in the CEDA Archive. A growing number of JASMIN users are now realising the benefits of using the Globus service to provide reliable and efficient data movement and other tasks in this and other contexts. Further use cases involve long-distance (intercontinental) transfers to and from JASMIN, and collecting results from a mobile atmospheric radar system, pushing data to JASMIN via a lightweight Globus deployment. We provide details of how Globus fits into our current infrastructure, our experience of the recent migration to GCSv5.4, and of our interest in developing use of the wider ecosystem of Globus services for the benefit of our user community.
Designing for Privacy in Amazon Web ServicesKrzysztofKkol1
Data privacy is one of the most critical issues that businesses face. This presentation shares insights on the principles and best practices for ensuring the resilience and security of your workload.
Drawing on a real-life project from the HR industry, the various challenges will be demonstrated: data protection, self-healing, business continuity, security, and transparency of data processing. This systematized approach allowed to create a secure AWS cloud infrastructure that not only met strict compliance rules but also exceeded the client's expectations.
Exploring Innovations in Data Repository Solutions - Insights from the U.S. G...Globus
The U.S. Geological Survey (USGS) has made substantial investments in meeting evolving scientific, technical, and policy driven demands on storing, managing, and delivering data. As these demands continue to grow in complexity and scale, the USGS must continue to explore innovative solutions to improve its management, curation, sharing, delivering, and preservation approaches for large-scale research data. Supporting these needs, the USGS has partnered with the University of Chicago-Globus to research and develop advanced repository components and workflows leveraging its current investment in Globus. The primary outcome of this partnership includes the development of a prototype enterprise repository, driven by USGS Data Release requirements, through exploration and implementation of the entire suite of the Globus platform offerings, including Globus Flow, Globus Auth, Globus Transfer, and Globus Search. This presentation will provide insights into this research partnership, introduce the unique requirements and challenges being addressed and provide relevant project progress.
top nidhi software solution freedownloadvrstrong314
This presentation emphasizes the importance of data security and legal compliance for Nidhi companies in India. It highlights how online Nidhi software solutions, like Vector Nidhi Software, offer advanced features tailored to these needs. Key aspects include encryption, access controls, and audit trails to ensure data security. The software complies with regulatory guidelines from the MCA and RBI and adheres to Nidhi Rules, 2014. With customizable, user-friendly interfaces and real-time features, these Nidhi software solutions enhance efficiency, support growth, and provide exceptional member services. The presentation concludes with contact information for further inquiries.
1. Welcome to Usable APIs at Scale!
We'll use a Google Compute Engine Virtual Machine in our
examples.
Get a free Google Cloud account at
https://cloud.google.com/free.
Install the Google Cloud SDK.
https://cloud.google.com/sdk/
Clone the Kiosk API repository.
% git clone github.com/googleapis/kiosk
2. Usable APIs at Scale
With Protocol Buffers and gRPC
Tim Burks, Joe Bolinger, Andrew Gunsch
Google
APIStrat 2018
3. We’re talking about Networked APIs
From the Google Cloud APIs Design Guide:
Networked APIs
Application Programming Interfaces that operate across a network of
computers. They communicate using network protocols including HTTP, and
are frequently produced by different organizations than the ones that
consume them.
8. October 4, 2000
CL 23852 by jeff
ProtocolBuffer, a class for encoding hierarchical data in a compact
binary form. Initially to be used for sending raw posting list data
out from the qserver to clients that want to do their own scoring.
Co-designed and Rev. by Sanjay
9. Protocol Buffers is a language-neutral, platform-neutral, extensible mechanism
for serializing structured data.
10. “Protocol Buffers” means several things
1. A serialization mechanism
2. An interface description language
3. A methodology
11. Protocol Buffer Serialization
A message is just a stream of bytes
[field_number<<3 + wire_type] [length if necessary][data]...
$ hexdump /tmp/request.bin
0000000 0a 05 68 65 6c 6c 6f
0a is “0000 1010”, so
field_number = 1 and wire_type = 2
13. Protocol Buffer Methodology
% protoc echo.proto --go_out=.
# This runs the Protocol Buffer Compiler
# (https://github.com/protocolbuffers/protobuf/releases)
#
# with a plugin called protoc-gen-go
#
# The plugin generates a Go source file that implements
# the data structures defined in echo.proto and code
# for reading and writing them as serialized bytes.
15. gRPC
Open-Source messaging system based on Google’s internal API architecture.
Used for code and documentation generation, API management, and support
services for APIs and microservices running at very large scale.
16. gRPC is owned by the Cloud Native Computing Foundation
17. gRPC Adoption
Microservices: in data centres
Streaming telemetry from network devices
Client Server communication/Internal APIs
Mobile Apps
18. gRPC
Transport Mechanism
Client → Server
Server → Client
Initial
Metadata
MsgMsg
End of
Stream
Status & Trailing
Metadata
Initial
Metadata
MsgMsg Msg
HTTP/2
22. Describing the API
Kiosks
// Describes a hardware device that can display signs.
message Kiosk {
string id = 1; // unique id
string device_name = 2; // name of device hardware
ScreenSize size = 3; // screen size
LatLng location = 4; // kiosk location
Timestamp create_time = 5;
}
23. Describing the API
ScreenSizes
// Represents the size of a screen in pixels.
message ScreenSize {
int32 width = 1; // screen width
int32 height = 2; // screen height
}
24. Describing the API
Signs
// Describes a digital sign.
// Signs can include text, images, or both.
message Sign {
string id = 1; // unique id
string text = 2; // text to display
bytes image = 3; // image to display
Timestamp create_time = 4;
}
25. Describing the API: RPCs
Operation
● GetSignForKiosk
● GetSignsForKiosk
Kiosks
● Create
● List
● Get
● Delete
Control
● SetSignForKiosks
Signs
● Create
● List
● Get
● Delete
called from
controllers
called from
kiosks
hardware
devices
displayed
on kiosks
30. Generate Kiosk Glue Code
git clone https://github.com/googleapis/api-common-protos
go get github.com/golang/protobuf/protoc-gen-go
go get google.golang.org/grpc
mkdir -p generated
protoc kiosk.proto
-I api-common-protos
-I .
--go_out=plugins=grpc:generated
31. Implement Kiosk Server Interface
type DisplayClient interface {
CreateKiosk(ctx context.Context, in *Kiosk,
opts ...grpc.CallOption) (*Kiosk, error)
ListKiosks(ctx context.Context, in *google_protobuf.Empty,
opts ...grpc.CallOption) (*ListKiosksResponse, error)
GetKiosk(ctx context.Context, in *GetKioskRequest,
opts ...grpc.CallOption) (*Kiosk, error)
DeleteKiosk(ctx context.Context, in *DeleteKioskRequest,
opts ...grpc.CallOption) (*google_protobuf.Empty, error)
...
GetSignIdsForKioskId(ctx context.Context, in *GetSignIdForKioskIdRequest,
opts ...grpc.CallOption) (Display_GetSignIdsForKioskIdClient, error)
}
32. Try the API with a CLI
$ k
Usage:
k create kiosk <name>
k list kiosks
k get kiosk <kiosk_id>
k delete kiosk <kiosk_id>
k create sign <name> [--text=<text>] [--image=<image>]
k list signs
k get sign <sign_id>
k delete sign <sign_id>
k set sign <sign_id> for kiosk <kiosk_id>
k set sign <sign_id> for all kiosks
k get sign for kiosk <kiosk_id>
k get signs for kiosk <kiosk_id>
33. Let’s try it.
Be sure that you have the Google Cloud SDK.
https://cloud.google.com/sdk/
% git clone github.com/googleapis/kiosk
% cd kiosk/gce
% ./SETUP.sh <project-id> <instance-name>
34. Generate and Publish API Client Libraries
“Make it easier to use Google APIs”
1. Hide implementation details from API consumers.
2. Develop API clients faster.
3. Improve API client quality (better performance, fewer bugs).
35. Recent API Client Work
2010 Google API Discovery Format, Automatically-generated clients
2014 Veneer (handwritten clients, measurably improved usability)
2015 Scalable Veneer/Veneer Toolkit
Centralized and monolithic code generation
7 languages
21 Cloud APIs by March 2018
2018 API Client Tools
Decentralized and standardized code generation
More languages
More APIs
42. Long-Running Operations
SpeechClient speechClient = SpeechClient.create();
OperationFuture<LongRunningRecognizeResponse> recognizeOperation =
speechClient.longRunningRecognizeAsync(config, audio);
…
LongRunningRecognizeResponse response = recognizeOperation.get();
● Java: OperationFuture
○ Polls the service until the LRO is done
○ Provides metadata as the LRO is in progress
○ Provides the final result
50. Manage Your Service With Endpoints
Develop, deploy and manage APIs on any Google Cloud Platform backend.
● User Authentication via JSON Web Token validation
● Logging and Monitoring
● API Keys
● Easy integration + deployment
51. Endpoints Architecture
GCE, GKE, Kubernetes or App Engine
Flexible
Environment Instance
GCE, GKE, Kubernetes or App Engine Flexible
Environment Instance (or off-GCP)
Extensible Service
Proxy Container
API Container
Google Service
Management API
User
Code
api
calls
gcloud
Config
deployment
Google Cloud
Console
Google Service
Control API
config Runtime
check & report
Load
balanci
ng
Stackdriver
Metrics &
logs
Metrics &
logs
visualized
53. Describing the Service
type: google.api.Service
config_version: 3
name: my-api.endpoints.my-gcp-project.cloud.goog
title: Kiosk gRPC API
apis:
- name: kiosk.Display
54. Starting Endpoints Proxy in Front of Application
gcloud endpoints services deploy service.yaml kiosk_descriptor.pb
./endpoints/START_ENDPOINTS_PROXY.sh my-gcp-project my-api <keyfile>
55. $ export KIOSK_PORT=8083
$ k list kiosks
FROM localhost:8083 LIST KIOSKS
rpc error: code = Unauthenticated
desc = Method doesn't allow
unregistered callers (callers
without established identity).
Please use API Key or other form of
API consumer identity to call this
API.
Starting Endpoints Proxy in Front of Application
56. $ export KIOSK_APIKEY=AIzaSy[...]bBo
$ k list kiosks
FROM localhost:8083 2018/09/21 19:08:25 Using API key: AIzaSy[...]bBo
LIST KIOSKS
id:1 name:"HTTP Kiosk" size:<width:1080 height:720 >
id:2 name:"HTTP Kiosk" size:<width:1080 height:720 >
Getting an API Key
59. # Add a kiosk
$ curl -d '{"name":"HTTP Kiosk", "size": { width: 1080, height: 720 } }'
localhost:8082/v1/kiosks?key=AIzaSy[...]bBo
# Get kiosk
$ curl localhost:8082/v1/kiosks/1?key=AIzaSy[...]bBo
Now you can use HTTP+JSON!