Tag Archives: apis

A Tool for Exploring and Testing Google Workspace APIs

Posted by Chanel Greco, Developer Advocate Google Workspace

We recently launched the Google Workspace APIs Explorer, a new tool to help streamline developing on the Google Workspace Platform. What is this handy tool and how can you start using it?

The Google Workspace APIs Explorer is a tool that allows you to explore and test Google Workspace APIs without having to write any code. It's a great way to get familiar with the capabilities of the many Google Workspace APIs.

The Google Workspace APIs Explorer is a web-based tool that allows you to interact with Google Workspace APIs in a visual way.

Screenshot of Google Workspace API Explorer

How to use the Google Workspace APIs Explorer

To use this tool, simply navigate to the Google Workspace APIs Explorer page and select the API that you want to explore. The Google Workspace APIs Explorer will then display a list of all the methods available for that API. You can click on any method to see more information about it, including its parameters, responses, and examples.

To test an API method, simply enter the required parameters and click on the "Execute" button. The Google Workspace APIs Explorer will then send the request to the API and return the response. Please note, the tool acts on real data and authenticates with your Google Account, so use caution when trying methods that create, modify, or delete data.

Screenshot of Google Sheets API get in Google workspace API Explorer
Click to enlarge

How you can benefit from using the Google Workspace APIs Explorer

These are some of the benefits of using the Google Workspace APIs Explorer:

  • You can browse and discover the 25+ different Google Workspace APIs.
  • The tool can help you create code samples for your integrations or add-ons.
  • It can assist with troubleshooting problems with Google Workspace APIs.
  • It is a neat way to see the results of API requests in real time.

Getting started

You can access the Google Workspace APIs Explorer tool on the Google Workspace for Developers documentation, either through the navigation (Resources > API Explorer), or on its dedicated page. You will need a Google account to use the tool. This account can either be a Google Workspace account or the Google account you use for accessing tools like Gmail, Drive, Docs, Calendar, and more.

We also have a video showing how you can get started using the Google Workspace APIs Explorer – check it out here!

PaLM API & MakerSuite: an approachable way to start prototyping and building generative AI applications

Posted by Scott Huffman, Vice President, Engineering and Josh Woodward, Senior Director, Product Management

We’re seeing a new wave of generative AI applications that are transforming the way people interact with technology – from games and dialog agents to creative brainstorming and coding tools. At Google, we want to continue making AI accessible by empowering all developers to start building the next generation of applications with generative AI by providing easy-to-use APIs and tools.

Earlier today, we announced the PaLM API, a new developer offering that makes it easy and safe to experiment with Google’s large language models. Alongside the API, we’re releasing MakerSuite, a tool that lets developers start prototyping quickly and easily. We’ll be making these tools available to select developers through a Private Preview, and stay tuned for our waitlist soon.

Access Google’s large language models using the PaLM API

The PaLM API is a simple entry point for Google’s large language models, which can be used for a variety of applications. It will provide developers access to models that are optimized for multi-turn use cases, such as content generation and chat, and general purpose models that are optimized for use cases such as summarization, classification, and more. Starting today, we’re making an efficient model available in terms of size and capabilities, and we’ll add other models and sizes soon.

Start building quickly

We’ve spent the last several years building and deploying large language models—from bringing MUM to Search to exploring applications with LaMDA in the AI Test Kitchen. We learned a lot about generative AI development workflows and how fragmented they can be. Developers have to use different tools to accomplish tasks like crafting and iterating on a prompt, generating synthetic data, and tuning a custom model.

That’s why we’re releasing MakerSuite, a tool that simplifies this workflow. With MakerSuite, you’ll be able to iterate on prompts, augment your dataset with synthetic data, and easily tune custom models. When you’re ready to move to code, MakerSuite will let you export your prompt as code in your favorite languages and frameworks, like Python and Node.js.

Tune a model

Generative models offer developers powerful out-of-the-box functionality. But for specialized tasks, tuning leads to better results. Our tooling will enable developers to leverage parameter-efficient tuning techniques to create models customized to their use case. And with MakerSuite, you’ll be able to quickly test and iterate on your tuned model right in the browser.

Augment your dataset with synthetic data

High-quality data is crucial when developing with AI, and developers are often limited by the data they have. Our tooling will allow you to generate additional data based on a few examples, and then you’ll be able to manage and manipulate the data from there. This synthetic data can be used in various scenarios, such as tuning or evaluations.

Generate state of the art embeddings

We’ve been excited by the range of applications developers have found for embeddings, from semantic search to recommendations and classification. With embeddings generated through the PaLM API, developers will be able to build applications with their own data or on top of external data sources. Embeddings can also be used in downstream applications built with TensorFlow, Keras, JAX, and other open-source libraries.

Build responsibly and safely

We built our models according to Google’s AI Principles to give developers a responsible AI foundation to start from. We know that control is necessary so developers can define and enforce responsibility and safety in the context of their own applications. Our tools will give developers an easy way to test and adjust safety dimensions to best suit each unique application and use case.

Scale your generative AI application

These developer tools will make it easy to start prototyping and building generative AI applications, but when you need scale, we want to make sure you have the support you need. Google's infrastructure supports the PaLM API and MakerSuite, so you don’t have to worry about hosting or serving. For developers who want to scale their ideas and get enterprise-grade support, security and compliance, and service level agreement (SLA), they can go to Google Cloud Vertex AI and access the same models, along with a host of advanced capabilities such as enterprise search and conversation AI.

It’s an exciting time in AI for developers and we want to continue to make sure we build AI tools that help make your lives easier. We plan to onboard new developers, roll out new features, and make this technology available to the broader developer community soon. During this time, we’ll listen to feedback, learn, and improve these tools to meet developers where they are.

To stay updated on our progress, subscribe to the Google Developers newsletter.

Migrating from App Engine Users to Cloud Identity Platform (Module 21)

Posted by Wesley Chun (@wescpy), Developer Advocate, Google Cloud

The Serverless Migration Station series is aimed at helping developers modernize their apps running one of Google Cloud's serverless platforms. The preceding (Migration Module 20) video demonstrates how to add use of App Engine's Users service to a Python 2 App Engine sample app. Today's Module 21 video picks up from where that leaves off, migrating that usage to Cloud Identity Platform.
How to migrate the App Engine Users to Cloud Identity Platform
Moving away from proprietary App Engine bundled services like Users makes apps more portable, giving them enough flexibility to:

    Understanding the overall migration

    Overall, Module 21 features major changes to the Module 20 sample app, implementing a move from App Engine bundled services (NDB & Users) to standalone Cloud services (Cloud Datastore & Identity Platform). Identity Platform doesn't know anything about App Engine admins, so that must be built, requiring the use of the Cloud Resource Manager API. Apps dependent on Python 2 have additional required updates. Let's discuss in a bit more detail.

    Migration "parts"

    The following changes to the sample app are required:

    • Migrate from App Engine Users (server-side) to Cloud Identity Platform (client-side)
    • Migrate from App Engine NDB, the other bundled service used in Module 20, to Cloud NDB (requires use of the Cloud Datastore API)
    • Use the Cloud Resource Manager* (via its API) to fetch the Cloud project's IAM allow policy to collate the set of App Engine admin users for the app.
    • Use the Firebase Admin SDK to validate whether the user is an App Engine admin
    • Migrate from Python 2 to 3 (and possibly back to Python 2 [more on this below])
     
    *At the time of this writing, the Resource Manager documentation only features setup instructions for accessing the API from the lower-level Google APIs client library rather than the Resource Manager client library. To learn how to set up the latter, go to the Resource Manager client library documentation directly. The lower-level client library should only be used in circumstances when a Cloud client library doesn't exist or doesn't have the features your app needs. One such use case is Python 2, and we'll be covering that shortly.
     

      Move from App Engine bundled services to standalone Cloud services

      The NDB to Cloud NDB migration is identical to the Module 2 migration content, so it's not covered in-depth here in Module 21. The primary focus is on switching to Identity Platform to continue supporting user logins as well as implementing use of the Resource Manager and Firebase Admin SDK to build a proxy for recognizing App Engine admin users as provided by the Users service. Below is pseudocode implementing the key changes to the main application where new or updated lines of code are bolded:

      Table showing changes in code 'Before'(Module 20) and 'After'(Module 21)
      Migrating from App Engine Users to Cloud Identity Platform(click to enlarge)

      The key differences to note:

      1. The server-side Users service code vanishes from the main application, moving into the (client-side) web template (not shown here).
      2. Practically all of the new code in the Module 21 app above is for recognizing App Engine admin users. There are no changes to app operations or data models other than Cloud NDB requiring use of Python context managers to wrap all Datastore code (using Python with blocks).

      Complete versions of the app before and after the updates can be found in the Module 20 (Python 2) and Module 21 (Python 3) repo folders, respectively. In addition to the video, be sure to check out the Identity Platform documentation as well as the Module 21 codelab which leads you step-by-step through the migrations discussed.

      Aside from the necessary coding changes as well as moving from server-side to client-side, note that the Users service usage is covered by App Engine's pricing model while Identity Platform is an independent Cloud service billed by MAUs (monthly active users), so costs should be taken into account if migrating. More information can be found in the Identity Platform pricing documentation.

      Python 2 considerations

      With the sunset of Python 2, Java 8, PHP 5, and Go 1.11, by their respective communities, Google Cloud has assured users by expressing continued long-term support of these legacy App Engine runtimes, including maintaining the Python 2 runtime. So while there is no current requirement for users to migrate, developers themselves are expressing interest in updating their applications to the latest language releases.
      The primary Module 21 migration automatically includes a port from Python 2 to 3 as that's where most developers are headed. For those with dependencies requiring remaining on Python 2, some additional effort is required:


        The codelab covers this backport in-depth, so check out the specific section for Python 2 users if you're in this situation. If you don't want to think about it, just head to the repo for a working Python 2 version of the Module 21 app.

        Wrap-up

        Module 21 features migrations of App Engine bundled services to appropriate standalone Cloud services. While we recommend users modernize their App Engine apps by moving to the latest offerings from Google Cloud, these migrations are not required. In Fall 2021, the App Engine team extended support of many of the bundled services to 2nd generation runtimes (that have a 1st generation runtime), meaning you don't have to migrate to standalone services before porting your app to Python 3. You can continue using App Engine NDB and Users in Python 3 so long as you retrofit your code to access bundled services from next-generation runtimes. Then should you opt to migrate, you can do so on your own timeline.

        If you're using other App Engine legacy services be sure to check out the other Migration Modules in this series. All Serverless Migration Station content (codelabs, videos, source code [when available]) can be accessed at its open source repo. While our content initially focuses on Python users, the Cloud team is working on covering other language runtimes, so stay tuned. For additional video content, check out our broader Serverless Expeditions series.

        How to use the App Engine Users service (Module 20)

        Posted by Wesley Chun (@wescpy), Developer Advocate, Google Cloud


        Introduction and background

        The Serverless Migration Station video series and corresponding codelabs aim to help App Engine developers modernize their apps, whether it's upgrading language runtimes like from Python 2 to 3 and Java 8 to 17, or to move laterally to sister serverless platforms like Cloud Functions or Cloud Run. For developers who want more control, like being able to SSH into instances, Compute Engine VMs or GKE, our managed Kubernetes service, are also viable options.

        In order to consider moving App Engine apps to other compute services, developers must move their apps away from its original APIs (now referred to as legacy bundled services), either to Cloud standalone replacement or alternative 3rd-party services. Once no longer dependent on these proprietary services, apps become much more portable. Apps can stay on App Engine while upgrading to its 2nd-generation platform, or move to other compute platforms as listed above.

        Today's Migration Module 20 content focuses on helping developers refamiliarize themselves with App Engine's Users service, a user authentication system serving as a lightweight wrapper around Google Sign-In (now called Google Identity Services). The video and its corresponding codelab (self-paced, hands-on tutorial) demonstrate how to add use of the Users service to the sample baseline app from Module 1. After adding the Users service in Module 20, Module 21 follows, showing developers how to migrate that usage to Cloud Identity Platform.

        How to use the App Engine Users service

        Adding use of Users service


        The sample app's basic functionality consists of registering each page visit in Datastore and displaying the most recent visits. The Users service helps apps support user logins, App Engine administrative ("admin'") users. It also provides convenient functions for generating login/logout links and retrieving basic user information for logged-in users. Below is a screenshot of the modified app which now supports user logins via the user interface (UI):
        Sample app now supports user logins and App Engine admin users (click to enlarge) 
        Below is the pseudocode reflecting the changes made to support user logins for the sample app, including integrating the Users service and updating what shows up in the UI:
        • If the user is logged in, show their "nickname" (display name or email address) and display a Logout button. If the logged-in user is an App Engine app admin, also display an "admin" badge (between nickname and Logout button).
        • If the user is not logged in, display the username generically as "user", remove any admin badge, and display a Login button.
        Because the Users service is primarily a user-facing endeavor, the most significant changes take place in the UI, whereas the data model and core functionality of registering visits remain unchanged. The new support for user management primarily results in additional context to be rendered in the web template. New or altered code is bolded to highlight the updates.
        Table showing code 'Before'(Module 1) on left, and 'After' (Module 20) on the right
         Adding App Engine Users service usage to sample app (click to enlarge)

        Wrap-up


        Today's "migration" consists of adding usage of the App Engine Users service to support user management and recognize App Engine admin users, starting with the Module 1 baseline app and finishing with the Module 20 app. To get hands-on experience doing it yourself, try the codelab and follow along with the video. Then you'll be ready to upgrade to Identity Platform should you choose to do so.

        In Fall 2021, the App Engine team extended support of many of the bundled services to 2nd generation runtimes (that have a 1st generation runtime), meaning you are no longer required to migrate from the Users service to Identity Platform when porting your app to Python 3. You can continue using the Users service in your Python 3 app so long as you retrofit the code to access bundled services from next-generation runtimes.

        If you do want to move to Identity Platform, see the Module 21 content, including its codelab. All Serverless Migration Station content (codelabs, videos, and source code [when available]) are available at its open source repo. While we're initially focusing on Python users, the Cloud team is covering other runtimes soon, so stay tuned. Also check out other videos in the broader Serverless Expeditions series.

        Migrating from App Engine pull tasks to Cloud Pub/Sub (Module 19)

        Posted by Wesley Chun (@wescpy), Developer Advocate, Google Cloud

        Introduction and background

        The Serverless Migration Station series is aimed at helping developers modernize their apps running one of Google Cloud's serverless platforms. The preceding (Migration Module 18) video demonstrates how to add use of App Engine's Task Queue pull tasks service to a Python 2 App Engine sample app. Today's Module 19 video picks up from where that leaves off, migrating that pull task usage to Cloud Pub/Sub.

        Moving away from proprietary App Engine services like Task Queue makes apps more portable, giving them enough flexibility to:

         

          Understanding the migrations

          Module 19 consists of implementing three different migrations on the Module 18 sample app:

          • Migrate from App Engine NDB to Cloud NDB
          • Migrate from App Engine Task Queue pull tasks to Cloud Pub/Sub
          • Migrate from Python 2 to Python (2 and) 3

          The NDB to Cloud NDB migration is identical to the Module 2 migration content, so it's not covered in-depth in Module 19. The original app was designed to be Python 2 and 3 compatible, so there's no work there either. Module 19 boils down to three key updates:

          • Setup: Enable APIs and create Pub/Sub Topic & Subscription
          • How work is created: Publish Pub/Sub messages instead of adding pull tasks
          • How work is processed: Pull messages instead of leasing tasks

          Aside from these physical changes, a key hurdle to overcome is understanding the differences in terminology between pull tasks and Pub/Sub. The following chart attempts to demystify this so developers can more easily grasp how they differ:
          Table of terminology with related GAE Pull Tasks and Cloud Pub/Sub
          Terminology differences between App Engine pull tasks and Cloud Pub/Sub

          Reflecting the chart, these differences can be summarized like this:
          1. With Pull Queues, work is created in pull queues while work is sent to Pub/Sub topics
          2. Task Queue pull tasks are called messages in Pub/Sub
          3. With Task Queues, workers access pull tasks; with Pub/Sub, subscribers receive messages
          4. Leasing a pull task is the same as pulling a message from a Pub/Sub topic via a subscription
          5. Deleting a task from a pull queue when you're done is analogous to successfully acknowledging a Pub/Sub message
          The video walks developers through the terminology as well as the code changes described above. Below is pseudocode implementing the key changes to the main application (new or updated lines of code bolded):
          Table showing changes in code Before (Module 18) on the left, and After (Module 19) on the right
          Migration from App Engine Task Queue pull tasks to Cloud Pub/Sub

          Observe how most of the code, especially app operations and data models are left relatively unchanged. The only visible changes are switching from App Engine NDB and Task Queue to Cloud NDB and Pub/Sub. Complete versions of the app before and after making the changes can be found in the Module 18 and Module 19 repo folders, respectively. In addition to the video, be sure to check out the Module 19 codelab which leads you step-by-step through the migrations discussed.

          Wrap-up

          Module 19 features a migration of App Engine pull tasks to Cloud Pub/Sub, but developers should note that Pub/Sub itself is not based on pull tasks. It is a fully-featured asynchronous, scalable messaging service that has many more features than the pull functionality provided by Task Queue. For example, Pub/Sub has other features like streaming to BigQuery and push functionality. Pub/Sub push operates differently than Task Queue push tasks, hence why we recommend push tasks be migrated to Cloud Tasks instead (see Module 8). For more information on all of its features, see the Pub/Sub documentation. Because Cloud Tasks doesn't support pull functionality, we turn to Pub/Sub instead for pull task users.

          While we recommend users move to the latest offerings from Google Cloud, neither of those migrations are required, and should you opt to do so, can do them on your own timeline. In Fall 2021, the App Engine team extended support of many of the bundled services to 2nd generation runtimes (that have a 1st generation runtime), meaning you don't have to migrate to standalone Cloud services before porting your app to Python 3. You can continue using Task Queue in Python 3 so long as you retrofit your code to access bundled services from next-generation runtimes.

          If you're using other App Engine legacy services be sure to check out the other Migration Modules in this series. All Serverless Migration Station content (codelabs, videos, source code [when available]) can be accessed at its open source repo. While our content initially focuses on Python users, the Cloud team is working on covering other language runtimes, so stay tuned. For additional video content, check out our broader Serverless Expeditions series.

          Year in Review: 12 awesome ways for developers to learn, build, and grow with Google Workspace

          Posted by Matthew Izatt, Product Lead, Google Workspace Platform

          For millions of our customers, 2022 brought an abundance of change in the way they connect, collaborate, and get things done. Frontline workers at customers like Globe Telecom and general contractor BHI benefited from digital transformation on all fronts by quickly getting the apps they needed to do their jobs in the field. Office and remote workers, meanwhile, adjusted to hybrid work by leveraging ready-made tools from partners like DocuSign and Asana or they built custom desk booking applications.

          2022 was also a year of growth. Google Workspace now has more than 3 billion users and over 8 million paying customers across the globe. And the Google Workspace Marketplace passed a lifetime milestone of driving more than 5 billion app installs. To wrap up a year marked by so much change, we’ve recapped some of the biggest updates that make Google Workspace the most open and extensible platform for users, customers, and developers alike.

          1.    Build software with more agility with our DevOps integrations

            Google Workspace gives you real-time visibility into project progress and decisions to help you ship quality code fast and stay connected with your stakeholders, all without switching tools and tabs. By leveraging integrated applications from our partners, you can pull valuable information out of silos, making collaborating on requirements docs, code reviews, bug triage, deployment updates, and monitoring operations easy for the whole team. This year we partnered with popular DevOps tools to help you do your job better:

            • Asana: Plan and execute together, with Asana integrations you can coordinate and manage everything from daily tasks to cross-functional strategic initiatives.
            • GitHub: Teams can quickly push new commits, make pull requests, do code reviews, and provide real-time feedback that improves the quality of their code—all from Google Chat.
            • Jira: Accelerate the entire QA process in the development workflow. The Jira for Google Chat app acts as a team member in the conversation, sending new issues and contextual updates as they are reported to improve the quality of your code and keep everyone informed on your Jira projects.
            • PagerDuty: Enables developers, DevOps, IT operations, and business leaders to prevent and resolve business-impacting incidents for an exceptional customer experience—all from Google Chat.
             
            2.    Apply to our Developer Preview Program: get early access to upcoming platform features

            This year we launched the Google Workspace Developer Preview program to get you access to the new APIs and stay in touch with the latest updates on the Google Workspace platform. Features in developer preview have already completed early development phases, so they're ready for implementation. This program gives you the chance to shape the final stages of feature development with feedback, get pre-release support, and have your integration ready for public use on launch day. Apply to the Developer Preview Program today.

            For Google Chat this year we announced that you could programmatically create new spaces and add members on behalf of users via the Google Chat API. These latest additions to the Chat API unlock some sought-after scenarios for developers looking for new ways to extend Chat. For example, PagerDuty leveraged the API as part of their PagerDuty for Google Chat app. The app allows the incident team to isolate and focus on the problem at hand without being distracted by having to set up a new space, or further distract any folks in the current space who aren’t a part of the resolution team for a specific incident. All of this will be done seamlessly through PagerDuty for Chat as part of the natural flow of working with Google Chat.

            Screen grab of PagerDuty for Google Chat keeping a demo business up to date on service-impacting incidents.
            PagerDuty for Google Chat keeps the business up to date on service-impacting incidents.

            We are adding functionality to Chat apps so developers can soon add widgets like a date time picker, or design their layout with multiple columns to make better use of space. We believe these new layout options will open more ways for developers to build engaging apps for users. To help users find and learn more about apps we’ve added “About pages” for apps and making apps discoverable in the compose bar in Chat. Apply to our Developer Preview Program to get early access to the Google Chat APIs.

            We also announced new functionality for app developers to leverage the Google Meet video conferencing product through our new Meet Live Sharing API. Users can now come together and share experiences with each other inside an app, such as streaming a TV show, queuing up videos to watch on YouTube, collaborating on a music playlist, joining in a dance party, or working out together though Google Meet. If you want to try out the APIs, you can apply for access through the Developer Preview Program.

            Moving image showing how Miro for Google Meet uses the new Meet APIs for an integrated experience within Meet.
            Miro for Google Meet uses the new Meet APIs for an integrated experience within Meet.

            3.    Connect your customers with critical information with Smart Chips for Google Docs

              We expanded smart chips to our ecosystem of partners, allowing our users to add even more rich data, more context, and critical information right into the flow of their work. With these new third-party smart chips, you will be able to tag and see critical information from partner applications using @-mentions, and easily insert interactive information and previews from third-party apps directly into a Google Doc. Several of our partners, including AO Docs, Atlassian, Asana, Figma, Miro, Tableau, and ZenDesk, are now developing third-party smart chips to add more value to your Google Docs experience. Smart chips will be available to developers to build out their app integrations in 2023.

              Moving image showing how Smart Chips work in Google docs
              Smart Chips will be available to third-party developers in 2023.

              4.    Grow your business with the Recommended for Google Workspace program

              Each year, we evaluate the apps on Google Workspace Marketplace and recommend a select number that are enhancing the Google Workspace experience and helping people work in powerful new ways. Each undergoes reviews by both Google and an independent third-party security firm to ensure they meet our highest standards of integration and security requirements. For 2022 here’s the selection of Recommended for Google Workspace: AODocs, Copper, Dialpad, DocuSign, LumApps, Mailmeteor, Miro, RingCentral, Sheetgo, Signeasy, Supermetrics, and Yet Another Mail Merge. Our application for Recommended for Google Workspace is now open, apply today.

              Recommended for Google Workspace 2023 application is open!
              Become an app Recommended for Google Workspace for 2023, apply today.

              5.    Manage Google Workspace APIs with ease

                We recently added a unified way to access Google Workspace APIs through the Google Cloud Console—APIs for Gmail, Google Drive, Docs, Sheets, Chat, Slides, Calendar, and many more. From there, you now have a central location to manage all your Google Workspace APIs and view all of the aggregated metrics for the API in use. Watch this how-to video to get started.

                Google worksspace APIs in Cloud Console
                Developers can now manage their Google Workspace APIs from within the Google Cloud Console.

                6.    Create surveys, questionnaires, and quizzes and evaluate the results programmatically

                  The new Google Forms API joins the large family of APIs available to developers under Google Workspace. The Forms API provides programmatic access for managing forms, acting on responses, and empowering developers to build powerful integrations on top of Forms. Watch this introduction to the Google Forms API to get started.

                  Customer satisfaction Surveys created in Google Forms shown on desktop and mobile
                  The new Google Forms API allows you to programmatically create and manage Forms.

                  7.    Build intelligent business apps with No-Code and Low-Code

                    Google Apps Script is a low-code, cloud based JavaScript development environment for Google Workspace that makes it easy for anyone to build custom business solutions across several Google products. This year we completed the updates for our new IDE v2, offering a more modern and simplified development experience which makes it quicker and easier to build solutions that make Google Workspace apps more useful for your organization.

                    If you are new to Apps Script, figuring out where to begin can be a hurdle, this year we released 10 new sample solutions to help you get started to bring our number to more than 30! From data analysis to automated emails, you’ll find sample solutions to get you started quickly.

                    AppSheet is Google’s platform for building no-code custom apps and workflows to automate business processes. It lets app creators build and deploy end-to-end apps and automations without writing code.

                    The new Apps Script connector for AppSheet, launched this year, ties everything together: AppSheet, Apps Script, Google Workspace, and Google Workspace’s many developer APIs. This integration lets no-code app developers using AppSheet greatly extend the capabilities of their no-code apps by allowing them to call and pass data to Apps Script functions. One way to think about this integration is that it bridges no-code (AppSheet) with low-code (Apps Script).

                    AppSheet databases, announced in preview this year, is a built-in database for professional and citizen developers to easily and securely manage their data. AppSheet databases will give users access to an easy to use, first party database for creating and managing data. Get started and try AppSheet for free.

                    AppSheet database
                    AppSheet databases are now available in preview.

                    8.    Learn to build amazing solutions on our YouTube channel

                      This year, we introduced our dedicated YouTube channel for Google Workspace Developers. The channel serves as an ever-growing collection of our most helpful videos, allowing developers of all skill levels and interests to learn about building solutions with Google Workspace.

                      An example of a video you will find on the Google Workspace Developers channel: Anatomy of Google Chat apps - Basic interaction
                      Our new YouTube channel for Google Workspace developers has dozens of how-to videos for you.

                      9.    Connect with Cloud experts and community as a Google Cloud Innovator

                        Community building is one of the most effective ways to support developers, which is why we created Google Cloud Innovators.This new community program was designed for developers and technical practitioners using Google Cloud and everyone is welcome. In 2022, we kicked off the inaugural Innovators Hive, a live, interactive, and virtual event for our global Innovators community. Hive offered rich technical content presented by Champion Innovators and Google engineering leaders. Become a Google Cloud Innovator today.

                        Google Cloud Innovators logo in a solid black frame with text that reads 'Welcome, Innovators'
                        The Google Cloud Innovators program is open to all levels of creators and developers.

                        10.    Integrate and extend Google Workspace: top sessions from Google I/O

                          Learn about the latest innovations and discover how developers can integrate and extend Google Workspace. Here are a few of my favorite sessions from I/O:

                          Google I/O Logo

                          11.    Build the future of work: top sessions from Google Cloud Next

                          Watch on-demand videos from our biggest Cloud event of the year and learn from product experts and partners to level up your skills.


                          12.    Engage with the Google Workspace team and ecosystem at our Developer Summits

                          We also had our inaugural Google Workspace Developer Summit series take place in Paris and London. It was an amazing time meeting developers and IT teams from customers and partners that attended from throughout the EMEA region. Watch out for a summit near you in 2023 to learn more about the latest development features for Google Workspace from our Developer Advocates and build connections with the developer community, subscribe to our newsletter to get notified.

                          Photo of Developers listening to a presentation at Google Paris during Google Workplace Developer Summit
                          Developers gather at Google Paris for the Google Workspace Developer Summit.

                          2022 Wrap-up

                          We are thankful to you in helping make 2022 a great year for the Google Workspace developer community. We look forward to announcing more innovations and having more conversations with you in 2023. To keep track of all the latest announcements and developer updates for Google Workspace please subscribe to our monthly newsletter. Happy holidays and a peaceful New Year!

                          How to use App Engine pull tasks (Module 18)

                          Posted by Wesley Chun (@wescpy), Developer Advocate, Google Cloud

                          Introduction and background

                          The Serverless Migration Station mini-series helps App Engine developers modernize their apps to the latest language runtimes, such as from Python 2 to 3 or Java 8 to 17, or to sister serverless platforms Cloud Functions and Cloud Run. Another goal of this series is to demonstrate how to move away from App Engine's original APIs (now referred to as legacy bundled services) to Cloud standalone replacement services. Once no longer dependent on these proprietary services, apps become much more portable, making them flexible enough to:

                          App Engine's Task Queue service provides infrastructure for executing tasks outside of the standard request-response workflow. Tasks may consist of workloads exceeding request timeouts or periodic tangential work. The Task Queue service provides two different queue types, push and pull, for developers to perform auxiliary work.

                          Push queues are covered in Migration Modules 7-9, demonstrating how to add use of push tasks to an existing baseline app followed by steps to migrate that functionality to Cloud Tasks, the standalone successor to the Task Queues push service. We turn to pull queues in today's video where Module 18 demonstrates how to add use of pull tasks to the same baseline sample app. Module 19 follows, showing how to migrate that usage to Cloud Pub/Sub.

                          Adding use of pull queues

                          In addition to registering page visits, the sample app needs to be modified to track visitors. Visits are comprised of a timestamp and visitor information such as the IP address and user agent. We'll modify the app to use the IP address and track how many visits come from each address seen. The home page is modified to show the top visitors in addition to the most recent visits:

                          Screen grab of the sample app's updated home page tracking visits and visitors
                          The sample app's updated home page tracking visits and visitors

                          When visits are registered, pull tasks are created to track the visitors. The pull tasks sit patiently in the queue until they are processed in aggregate periodically. Until that happens, the top visitors table stays static. These tasks can be processed in a number of ways: periodically by a cron or Cloud Scheduler job, a separate App Engine backend service, explicitly by a user (via browser or command-line HTTP request), event-triggered Cloud Function, etc. In the tutorial, we issue a curl request to the app's endpoint to process the enqueued tasks. When all tasks have completed, the table then reflects any changes to the current top visitors and their visit counts:

                          Screen grab of processed pull tasks updated in the top visitors table
                          Processed pull tasks update the top visitors table

                          Below is some pseudocode representing the core part of the app that was altered to add Task Queue pull task usage, namely a new data model class, VisitorCount, to track visitor counts, enqueuing a (pull) task to update visitor counts when registering individual visits in store_visit(), and most importantly, a new function fetch_counts(), accessible via /log, to process enqueued tasks and update overall visitor counts. The bolded lines represent the new or altered code.

                          Adding App Engine Task Queue pull task usage to sample app showing 'Before'[Module 1] on the left and 'After' [Module 18] with altered code on the right
                          Adding App Engine Task Queue pull task usage to sample app

                          Wrap-up

                          This "migration" is comprised of adding Task Queue pull task usage to support tracking visitor counts to the Module 1 baseline app and arrives at the finish line with the Module 18 app. To get hands-on experience doing it yourself, do the codelab by hand and follow along with the video. Then you'll be ready to upgrade to Cloud Pub/Sub should you choose to do so.

                          In Fall 2021, the App Engine team extended support of many of the bundled services to 2nd generation runtimes (that have a 1st generation runtime), meaning you are no longer required to migrate pull tasks to Pub/Sub when porting your app to Python 3. You can continue using Task Queue in your Python 3 app so long as you retrofit the code to access bundled services from next-generation runtimes.

                          If you do want to move to Pub/Sub, see Module 19, including its codelab. All Serverless Migration Station content (codelabs, videos, and source code) are available at its open source repo. While we're initially focusing on Python users, the Cloud team is covering other runtimes soon, so stay tuned. Also check out other videos in the broader Serverless Expeditions series.

                          Extending support for App Engine bundled services (Module 17)

                          Posted by Wesley Chun (@wescpy), Developer Advocate, Google Cloud

                          Background

                          App Engine initially launched in 2008, providing a suite of bundled services making it convenient for applications to access a database (Datastore), caching service (Memcache), independent task execution (Task Queue), Google Sign-In authentication (Users), or large "blob" storage (Blobstore), or other companion services. However, apps leveraging those services can only run their apps on App Engine.

                          To increase app portability and help Google move towards its goal of having the most open cloud on the market, App Engine launched its 2nd-generation service in 2018, initially removing those legacy services. The newer platform allows developers to upgrade apps to the latest language runtimes, such as moving from Python 2 to 3 or Java 8 to 11 (and today, Java 17). One of the major drawbacks to the 1st-generation runtimes is that they're customized, proprietary, and restrictive in what you can use or can't.

                          Instead, the 2nd-generation platform uses open source runtimes, meaning ability to follow standard development practices, use common/known idioms, and have fewer restrictions of 3rd-party libraries, and obviating the need to copy or "vendor" them with your code. Unfortunately, to use these newer runtimes, migrating away from App Engine services were required because while you could upgrade language releases, there was no access to bundled services, breaking apps or requiring complete rewrites, making it a showstopper for many users.

                          Due to their popularity and the desire to ease the upgrade process for customers, the App Engine team restored access to most (but not all) of those services in Fall 2021. Today's Serverless Migration Station video demonstrates how to continue usage of bundled services available to Python 3 developers.

                          Showing App Engine users how to use bundled services on Python 3


                          Performing the upgrade

                          Modernizing the typical Python 2 App Engine app looks something like this:
                          1. Migrate from the webapp2 framework (not available in Python 3)
                          2. Port from Python 2 to 3, preserve use of bundled services
                          3. Optional migration to Cloud standalone or similar 3rd-party services

                          The first step is to move to a standard Python web framework like Flask, Django, Pyramid, etc. Below is some pseudocode from Migration Module 1 demonstrating how to migrate from webapp2 to Flask:

                          codeblocks for porting Python 2 sample app from webapp2 to Flask
                          Step 1: Port Python 2 sample app from webapp2 to Flask

                          The key changes are bolded in the above code snippets. Notice how the App Engine NDB code [the Visit class definition plus store_visit() and fetch_visits() functions] are unaffected by this web framework migration. The full webapp2 code sample can be found in the Module 0 repo folder while the completed migration to Flask sample is located in the Module 1 repo folder.

                          After your app has ported frameworks, you're free to upgrade to Python 3 while preserving access to the bundled services if your app uses any. Below is pseudocode demonstrating how to upgrade the same sample app to Python 3 as well as the code changes needed to continue to use App Engine NDB:

                          codeblocks for porting sample app to Python 3, preserving use of NDB bundled service
                          Step 2: Port sample app to Python 3, preserving use of NDB bundled service

                          The original app was designed to work under both Python 2 and 3 interpreters, so no language changes were required in this case. We added an import of the new App Engine SDK followed by the key update wrapping the WSGI object so the app can access the bundled services. As before, the key updates are bolded. Some updates to configuration are also required, and those are outlined in the documentation and the (Module 17) codelab.

                          The NDB code is also left untouched in this migration. Not all of the bundled services feature such a hands-free migration, and we hope to cover some of the more complex ones ahead in Module 22. Java, PHP, and Go users have it even better, requiring fewer or no code changes at all. The Python 2 Flask sample is located in the Module 1 repo folder, and the resulting Python 3 app can be found in the Module 1b repo folder.

                          The immediate benefit of step two is the ability to upgrade to a more current version of language runtime. This leaves the third step of migrating off the bundled services as optional, especially if you plan on staying on App Engine for the long-term.


                          Additional options

                          If you decide to migrate off the bundled services, you can do so on your own timeline. It should be a consideration should you ever want to move to modern serverless platforms such as Cloud Functions or Cloud Run, to lower-level platforms because you want more control, like GKE, our managed Kubernetes service, or Compute Engine VMs.

                          Step three is also where the rest of the Serverless Migration Station content may be useful:

                          *code samples and codelabs available; videos forthcoming

                          As far as moving to modern serverless platforms, if you want to break apart a large App Engine app into multiple microservices, consider Cloud Functions. If your organization has added containerization as part of your software development workflow, consider Cloud Run. It's suitable for apps if you're familiar with containers and Docker, but even if you or your team don't have that experience, Cloud Buildpacks can do the heavy lifting for you. Here are the relevant migration modules to explore:


                            Wrap-up

                            Early App Engine users appreciate the convenience of the platform's bundled services, and after listening to user feedback, adding them back to 2nd-generation runtimes is another way we can help developers modernize their apps. Whether upgrading to newer language runtimes to stay on App Engine and continue to use its bundled services, migrating to Cloud standalone products, or shifting to other serverless platforms, the Google Cloud team aims to provide the tools to help streamline your modernization efforts.

                            All Serverless Migration Station content (codelabs, videos, source code [when available]) can be accessed at its open source repo. While our content initially focuses on Python users, the Cloud team is working on covering other language runtimes, so stay tuned. Today's video features a special guest to provide a teaser of what to expect for Java. For additional video content, check out the broader Serverless Expeditions series.

                            How can App Engine users take advantage of Cloud Functions?

                            Posted by Wesley Chun (@wescpy), Developer Advocate, Google Cloud

                            Introduction

                            Recently, we discussed containerizing App Engine apps for Cloud Run, with or without Docker. But what about Cloud Functions… can App Engine users take advantage of that platform somehow? Back in the day, App Engine was always the right decision, because it was the only option. With Cloud Functions and Cloud Run joining in the serverless product suite, that's no longer the case.

                            Back when App Engine was the only choice, it was selected to host small, single-function apps. Yes, when it was the only option. Other developers have created huge monolithic apps for App Engine as well… because it was also the only option. Fast forward to today where code follows more service-oriented or event-driven architectures. Small apps can be moved to Cloud Functions to simplify the code and deployments while large apps could be split into smaller components, each running on Cloud Functions.

                            Refactoring App Engine apps for Cloud Functions

                            Small, single-function apps can be seen as a microservice, an API endpoint "that does something," or serve some utility likely called as a result of some event in a larger multi-tiered application, say to update a database row or send a customer email message. App Engine apps require some kind web framework and routing mechanism while Cloud Function equivalents can be freed from much of those requirements. Refactoring these types of App Engine apps for Cloud Functions will like require less overhead, helps ease maintenance, and allow for common components to be shared across applications.

                            Large, monolithic applications are often made up of multiple pieces of functionality bundled together in one big package, such as requisitioning a new piece of equipment, opening a customer order, authenticating users, processing payments, performing administrative tasks, and so on. By breaking this monolith up into multiple microservices into individual functions, each component can then be reused in other apps, maintenance is eased because software bugs will identify code closer to their root origins, and developers won't step on each others' toes.

                            Migration to Cloud Functions

                            In this latest episode of Serverless Migration Station, a Serverless Expeditions mini-series focused on modernizing serverless apps, we take a closer look at this product crossover, covering how to migrate App Engine code to Cloud Functions. There are several steps you need to take to prepare your code for Cloud Functions:

                            • Divest from legacy App Engine "bundled services," e.g., Datastore, Taskqueue, Memcache, Blobstore, etc.
                            • Cloud Functions supports modern runtimes; upgrade to Python 3, Java 11, or PHP 7
                            • If your app is a monolith, break it up into multiple independent functions. (You can also keep a monolith together and containerize it for Cloud Run as an alternative.)
                            • Make appropriate application updates to support Cloud Functions

                              The first three bullets are outside the scope of this video and its codelab, so we'll focus on the last one. The changes needed for your app include the following:

                              1. Remove unneeded and/or unsupported configuration
                              2. Remove use of the web framework and supporting routing code
                              3. For each of your functions, assign an appropriate name and install the request object it will receive when it is called.

                              Regarding the last point, note that you can have multiple "endpoints" coming into a single function which processes the request path, calling other functions to handle those routes. If you have many functions in your app, separate functions for every endpoint becomes unwieldy; if large enough, your app may be more suited for Cloud Run. The sample app in this video and corresponding code sample only has one function, so having a single endpoint for that function works perfectly fine here.

                              This migration series focuses on our earliest users, starting with Python 2. Regarding the first point, the app.yaml file is deleted. Next, almost all Flask resources are removed except for the template renderer (the app still needs to output the same HTML as the original App Engine app). All app routes are removed, and there's no instantiation of the Flask app object. Finally for the last step, the main function is renamed more appropriately to visitme() along with a request object parameter.

                              This "migration module" starts with the (Python 3 version of the) Module 2 sample app, applies the steps above, and arrives at the migrated Module 11 app. Implementing those required changes is illustrated by this code "diff:"

                              Migration of sample app to Cloud Functions

                              Next steps

                              If you're interested in trying this migration on your own, feel free to try the corresponding codelab which leads you step-by-step through this exercise and use the video for additional guidance.

                              All migration modules, their videos (when published), codelab tutorials, START and FINISH code, etc., can be found in the migration repo. We hope to also one day cover other legacy runtimes like Java 8 as well as content for the next-generation Cloud Functions service, so stay tuned. If you're curious whether it's possible to write apps that can run on App Engine, Cloud Functions, or Cloud Run with no code changes at all, the answer is yes. Hope this content is useful for your consideration when modernizing your own serverless applications!

                            Migrating App Engine push queues to Cloud Tasks

                            Posted by Wesley Chun (@wescpy), Developer Advocate, Google Cloud

                            Banner image that shows the Cloud Task logo

                            Introduction

                            The previous Module 7 episode of Serverless Migration Station gave developers an idea of how App Engine push tasks work and how to implement their use in an existing App Engine ndb Flask app. In this Module 8 episode, we migrate this app from the App Engine Datastore (ndb) and Task Queue (taskqueue) APIs to Cloud NDB and Cloud Tasks. This makes your app more portable and provides a smoother transition from Python 2 to 3. The same principle applies to upgrading other legacy App Engine apps from Java 8 to 11, PHP 5 to 7, and up to Go 1.12 or newer.

                            Over the years, many of the original App Engine services such as Datastore, Memcache, and Blobstore, have matured to become their own standalone products, for example, Cloud Datastore, Cloud Memorystore, and Cloud Storage, respectively. The same is true for App Engine Task Queues, whose functionality has been split out to Cloud Tasks (push queues) and Cloud Pub/Sub (pull queues), now accessible to developers and applications outside of App Engine.

                            Migrating App Engine push queues to Cloud Tasks video

                            Migrating to Cloud NDB and Cloud Tasks

                            The key updates being made to the application:

                            1. Add support for Google Cloud client libraries in the app's configuration
                            2. Switch from App Engine APIs to their standalone Cloud equivalents
                            3. Make required library adjustments, e.g., add use of Cloud NDB context manager
                            4. Complete additional setup for Cloud Tasks
                            5. Make minor updates to the task handler itself

                            The bulk of the updates are in #3 and #4 above, and those are reflected in the following "diff"s for the main application file:

                            Screenshot shows primary differences in code when switching to Cloud NDB & Cloud Tasks

                            Primary differences switching to Cloud NDB & Cloud Tasks

                            With these changes implemented, the web app works identically to that of the Module 7 sample, but both the database and task queue functionality have been completely swapped to using the standalone/unbundled Cloud NDB and Cloud Tasks libraries… congratulations!

                            Next steps

                            To do this exercise yourself, check out our corresponding codelab which leads you step-by-step through the process. You can use this in addition to the video, which can provide guidance. You can also review the push tasks migration guide for more information. Arriving at a fully-functioning Module 8 app featuring Cloud Tasks sets the stage for a larger migration ahead in Module 9. We've accomplished the most important step here, that is, getting off of the original App Engine legacy bundled services/APIs. The Module 9 migration from Python 2 to 3 and Cloud NDB to Cloud Firestore, plus the upgrade to the latest version of the Cloud Tasks client library are all fairly optional, but they represent a good opportunity to perform a medium-sized migration.

                            All migration modules, their videos (when available), codelab tutorials, and source code, can be found in the migration repo. While the content focuses initially on Python users, we will cover other legacy runtimes soon so stay tuned.