If you missed my previous post, Firebase 101: Authentication, I recommend starting there for a thorough explanation of what exactly Firebase is. We also covered, as you may have guessed from the title, authentication with Firebase and how to implement it.

As far as databases go, Firebase has two options to select from — Cloud Firestore and Realtime Database. On comparing the two, Google offers the below:

Cloud Firestore is Firebase’s newest database for mobile app development. It builds on the successes of the Realtime Database with a new, more intuitive data model. Cloud Firestore also features richer, faster queries and scales further than the Realtime Database.

Realtime Database is Firebase’s original database. It’s an efficient, low-latency solution for mobile apps that require synced states across clients in realtime.

If you’d like to learn more about Cloud Firestore, you can find the documentation here and checkout the below video. However, today we will be focusing on setting up and configuring a Realtime Database.

Realtime Database

Realtime Database is a NoSQL cloud database that prides itself on its realtime updates, scalability, and ability to operate offline. The realtime component is one of its most unique aspects. Data updates and database updates usually only happen when an HTTP request is made, a GET request updating the former and a POST or PATCH request updating the later. Inherently, this process relies on the client making that request, and updates will not happen otherwise.

Realtime Database uses something other than HTTP requests though for getting new data, which negates the need for client requests and facilitates this real-time updating. It uses data synchronization, meaning that whenever data is updated, all connected devices are automatically updated nearly instantaneously without the need for a new request. Think about that for a second. All connected devices anywhere are updated — that’s incredible.

Updates of course require a connection, but conveniently Realtime Database utilizes disk storage for the times that a user is offline. Users can still access the latest data from before they went offline, and as soon as they are reconnected, the data synchronization picks up where it left off and updates automatically.

In addition, Realtime Database can be used seamlessly with mobile applications, and has you covered when it comes to securing your application’s data. It offers Firebase Realtime Database Security Rules, allowing you to easily maintain control of permissions and rules as they pertain to your database. You can read more about these rules here.

Setting Up Realtime Database

From the Develop menu on the left hand side of your Firebase application, select “Database”. Scroll down to the “Or choose Realtime Database” section, and click on “Create database”.

You will see a prompt to start in locked mode or test mode. I am starting in test mode for this example, but depending on your needs you can select either one. And just like that, you have a Realtime Database and will be redirected to the dashboard for it.

Connecting to Realtime Database

To keep things simple, we will be covering connecting with a web application using JavaScript. iOS, Android, and languages other than JavaScript will have their own guides to connection.

First, set up your config folder and files, however you typically structure these. In this config file, use the below code to initialize your connection:

// Set the configuration for your appvar config = { apiKey: "", authDomain: ".firebaseapp.com", databaseURL: "https://databaseName.firebaseio.com", storageBucket: ".appspot.com" }; firebase.initializeApp(config); // Get a reference to the database service var database = firebase.database();

You will need to find your apiKey, projectId, databaseName, and bucket. Your database name can be found on the dashboard for your database, under the data tab:

To get your bucket, you will first need to configure a default storage bucket for your database. To do this, select “Storage” from the Develop menu, and then select “Get Started”.

You will be prompted to set the rules for your storage bucket, and then the location for your default storage bucket. Hit “Done” once completed and your default storage bucket will be created. You will be redirected to the dashboard for your new storage bucket, where you can find the bucket name for your database config file:

The remaining pieces are specific to the project rather than the database, and can be found in Project Settings:

Under the “General” tab, you can find your projectID and Web API Key:

And just like that, your Realtime Database is set up within Firebase and properly configured from within your codebase. Complete documentation for this database can be found here. Check back for more on Firebase’s Crashlytics and Analytics tools.

Originally published at https://www.syntx.io on January 9, 2020.

Firebase 101: Realtime Database was originally published in Syntx — News, Blog & Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of the things that I am most grateful for about being a software engineer in 2019, is the incredible breadth of SDKs, platforms, and tools that simplify the more complicated and often consistently repetitive tasks. Whether I am implementing a live commenting feature, adding charts to my UI, or deploying my finished product, there is a resource out there to save me from doing it from scratch. In this post, we are going to cover one of today’s most talked about, most used, and most important SDKs: Google’s Firebase.

What is Firebase?

For starters, Firebase is actually a collection of various products that all fall under the Firebase family. In Google’s own words, Firebase as a whole is described as the following:

Firebase gives you the tools to develop high-quality apps, grow your user base, and earn more money. We cover the essentials so you can monetize your business and focus on your users.

At the time of this article, Firebase is comprised of a total of 18 different products, in addition to 9 extensions. The products in this suite solve problems as simple as shortening URLs, and as complex as cloud messaging. The full list of products and extensions is below with links, for reference, and we will cover several of the most popular products in depth.

Products:

Extensions:

In my own development, I have mainly used Firebase’s authentication (Products #4), realtime database (Products #7), crashlytics (Products #8), and analytics (Products #13). Because this is where my own experience is, we are going to focus here on authentication, and will focus on each of the other three in future posts. I encourage you, though, to spend time exploring this suite and others. I learned recently that IBM’s cloud products even offers AI image recognition.

Getting Set Up with Firebase

When you first log in to Firebase, which you can do by simply being logged in to your Google account in your browser and clicking “Go to console” in the upper right hand corner here, you will come to a welcome screen.

The first thing you want to do is create a project using this screen’s prompt. It will ask you to input:

• The project’s name
• Whether or not you want to enable Google analytics for the project (I typically will enable)
• Configure Google analytics if you have enabled it

Once your project is ready, click continue and you will be taken to your project dashboard. One thing to note, is that each project can and likely will have multiple apps. iOS, Android, and web are each loaded in individually under one project.

Connecting to Firebase

To connect to Firebase, you need to set up a firebase config file in your codebase. In this file, you will add your firebaseConfig variable, which can be downloaded from Project → Settings → General → Your apps, where you will select the app that you are working on, then click the download google-services.json button:

This file will have the information that you need for the firebaseConfig variable:

And then your firebase app is initialized by just importing firebase and using this one line of code:

firebase.initializeApp(firebaseConfig);

Firebase Authentication

Before we dive into this, I would like to first say that, for those of you who have not, I strongly encourage that you first learn to build and implement authentication from the ground up. Building your own authentication system teaches you about encryption, hashing, and authentication flow, which in my opinion is extremely valuable knowledge. While it’s invaluable to have tools that strip you of the need to recreate something like authentication each time (and, let’s be honest, Google is doing it more securely than we could on our own anyway), it is still important to understand what it is that you are implementing. Now that that’s out of the way, let’s begin. Back to your Firebase console.

Setting up Firebase Auth

From the menu on the left hand side, select the “Develop” dropdown, and then select “Authentication”.

This dashboard is where you can manage everything related to users and authentication for your app. Firebase offers an authentication solution that supports traditional email/password auth, phone auth, and social auth such as Google and Facebook login. Firebase also stores all necessary user and login information in a Firebase database, so you don’t need to concern yourself with that part.

The users tab is where you can access a list of the project’s users and user information. You can also manually add users here.

The sign-in method tab allows you to enable your preferred social sign-in options, such as sign in through Google, Facebook, Twitter, Github, etc. The full list of options is pictured below. This shows a project with email/password, Google login, and Facebook login enabled.

On this same tab, under “Authorized domain”, you can (and need to) list domains to be authorized for OAuth redirects.

The templates tab very conveniently allows creation of templates for things like email verification and password reset, which are automatically triggered on signup and forgot password, respectively.

Lastly, the usage tab just displays the app usage statistics for the current billing period.

Implementing Firebase Auth

Firebase is now setup to receive, authenticate, and manage your users, and now just needs to be implemented into your codebase. The sign up and login flows here are really no different than the would be elsewhere. You can route as you would otherwise, but then when you get to the login and sign up functions, usually called under something like onClickLogin and onClickSignUp, you are going to use the below, where “firebaseMethod” is whichever firebase method is appropriate for your route:

firebase.auth().firebaseMethod(email, password)

So if you want to create a user, you would add the below line of code to your register/sign up function, where the email and password is taken from the user’s input:

firebase.auth().createUserWithEmailAndPassword(email, password)

And that’s it. Firebase has made a process which is complicated and costly to do right amazingly simple to implement. The full list of Firebase auth methods can be found here, and if you are using an auth provider, you can find that documentation here.

Check back for more on other Firebase products.

Originally published at https://www.syntx.io on December 13, 2019.

Firebase 101: Authentication was originally published in Syntx — News, Blog & Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

Async/Await: The Simplicity of Writing Asynchronous JavaScript

One of the defining qualities of JavaScript is that it is synchronous. It is single-threaded, meaning that at any one time only one block of JavaScript code on a page can be executed, and each line is executed one after the other. Seems simple enough, right? And it is, so long as you aren’t waiting on any data from an external source to be returned.

What happens, though, when you are sending a fetch request and need to use the return value of the request in the next block of code? Left to its own devices, the JavaScript engine will:

1. Make the fetch request
2. Return a special JavaScript object called a Promise
3. Move on to executing the next block of code
4. Either resolve the Promise or return an error once the request is complete
5. Continue executing the code synchronously, one block after another

The above sequence describes asynchronous JavaScript, because you can make that fetch request without blocking the thread. Your program can continue to execute code at the same time that the initial fetch request is processing and being completed.

Depending on the code, this sequence might be totally fine. Your program may not need the return value of the fetch request in order to run the subsequent code. Very often though, the code following the request needs that data being fetched in order to execute.

Before we get into asynchronous JavaScript, we are going to discuss what a Promise actually is. This is crucial to understanding asynchronous JavaScript, as it is only made possible by the return of a Promise object. If you already have a solid understanding of Promises, you can move on to the next section.

What Is a Promise?

A Promise is a special JavaScript object, and is called such because it really functions similarly to a promise in real life. Outside of software engineering, a promise refers to a commitment that someone makes to another person. I promise to do something, and you will see soon enough whether I fulfill or fail at that promise.

Promises in JavaScript are the same, but that “something” referred to above is a request. You make your fetch request, and get a Promise object back — a commitment to complete that fetch request, and shortly thereafter you find out whether that Promise is fulfilled or fails.

Here, “fulfilled” means successfully posting, getting, updating or deleting something from a database. “Fails” means you get an error that it was unsuccessful. The part that we want to focus on though is that “shortly thereafter” timeline. If your fetch request is returning a huge amount of data, this period of time will increase accordingly. But never is it instantaneous — not even for a small amount of data. A Promise is always returned, allowing the JavaScript engine to move on to executing the next block of code, but some Promises are resolved more quickly than others.

Asynchronous JavaScript

Asynchronous JavaScript is made possible thanks to Promises. If fetch requests did not return a Promise, the JavaScript engine would have to wait until the fetch request completes in order to move on to the next code block, because of its single threaded nature. For a large request that takes 30 seconds or even a couple of minutes, all code would be blocked from running until its completion — not a great user experience.

At times though, we need to wait. Hopefully the request we are waiting on only takes a couple of seconds or less, but either way, we need it to complete in order for the subsequent code to execute properly. For instance, if the next code block manipulates data returned from the request, executing that code won’t go very well if it’s done before the request completes.

If you have been working with JavaScript, you have likely seen the then/catch syntax used to handle just this problem. Then/catch works totally fine, but let’s be honest, it can get ugly fast. If you are chaining just one command it may be fine, but a series of commands can become messy and very hard to follow or work with.

Async/Await

Lucky for us, we have access to some syntactic sugar that does the exact same thing that a complex series of then/catch commands does with async/await. Instead of the long chain, all we need to do is use the ‘async’ keyword when defining a function, which will then allow you to use the ‘await’ keyword to specify to the engine which code blocks the program does need to wait on a response from before moving on. It’s that simple. You are telling the engine, “Hey, we’re going to have some asynchronous code in this function, but you need to wait for a response wherever you see ‘await’”.

The beauty of this option over then/catch, is that you can write the code exactly as you would otherwise and just add in a few keywords where needed. None of this wrapping entire code blocks into .then() and creating long convoluted chains. Take a look below at the same call written two different ways. The first uses then/catch, the second uses async/await:

const getUsersThen = () => {
 return fetch(`localhost:3000/users`, {
 method: 'GET',
 headers:{
 'Content-Type': 'application/json'
 }
 })
 .then(res => res.json())
 .then(res => {
 console.log(res)
 });
};

const getUsersAwait = async (req, res) => { const users = await fetch(`localhost:3000/users`, { method: 'GET', headers:{ 'Content-Type': 'application/json' } }); const usersJson = users.json(); console.log(usersJson); };

This is an extremely simple function in which we just log the JSON response to the console, but you can already see how much cleaner the async/await version is. This difference is magnified with every subsequent command — with every chained ‘then’ that no longer is needed. With async/await, writing asynchronous JavaScript just became infinitely more simple.

Originally published at https://www.syntx.io on November 27, 2019.

Async/Await: The Simplicity of Writing Asynchronous JavaScript was originally published in Syntx — News, Blog & Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

Advantages of React Native

With the majority of users now relying on mobile devices to access the internet, having a mobile app is a must for any business. As well as facilitating the sale of goods and services, a mobile app can be a great way to boost engagement and connect with your target audience.

Of course, in order to be effective, your mobile app must offer seamless functionality, high levels of security and enjoyable user experience. To achieve this, you’ll need to use a reliable and secure method of mobile app development.

What is React Native?

Creating a bridge between the JavaScript framework and native development, React Native makes it easy for companies and developers to create mobile apps. Whilst React Native ensures that apps can be developed for mobile devices, rather than targeting browsers, creators can rely on their existing knowledge of JavaScript to make this happen.

Generally, React Native mobile app development involves using JavaScript and XMLesque language. However, if only JavaScript and XML were used, creators would be forced to rely on webviews when it comes to rendering the app. With React Native, however, the native rendering APIs in iOS and Android systems are utilized. This means that mobile app development using React Native will result in apps that look, feel and work like any other native app, despite being built within the JavaScript framework.

Who uses React Native?

The is a vast network of companies already using React Native to create their mobile apps. In fact, many of the apps you’re currently using have probably been built using React Native! To date, apps, such as Tesla, Myntra, Gyroscope, UberEats, Instagram, Townske, Discovery VR, Bloomberg, and Facebook Ads Manager, have been created using React Native.

With some of the most popular companies and brands relying on React Native to deliver their apps to millions of users, it’s easy to see just how effective it is. Providing superb functionality and security, as well as exceptional UX, React Native is being used by the biggest brands in the world.

Of course, you don’t have to be a multinational company or a conglomerate to reap the rewards that React Native brings. Due to its scalability, React Native can be used by businesses of all sizes. Whether you’re an entrepreneur with a great idea for a mobile app, the owner of an established SME or the manager of a large, multinational firm, React Native can be used to create the perfect mobile app for your brand.

What are the advantages of React Native?

Mobile app development has skyrocketed in recent years and the vast majority of people expect businesses to have a functional app available on all major platforms. Historically, however, mobile app development could be costly, time-consuming and challenging for businesses. With limited in-house resources, many companies struggled to build the apps they wanted. Unsure where to turn to for assistance, some businesses decided to forego having a mobile app altogether, whilst others opted for limited functionality and minimal usage.

With the introduction of React Native, however, mobile app development has become easier than ever. Suitable for any organization, it has made mobile app development a reality for all types of businesses and ensured that functionality doesn’t come at the cost of straightforward, swift development.

Minimizing the costs of mobile app development

As React Native apps can be built using a familiar framework, more developers are now able to offer app development as a service. As a result, companies can access top-quality apps for a fraction of their previous costs. Whilst developers possess a range of specialist knowledge and skills, they can now use these skills across mobile app development and not be restricted solely to web development. For companies, entrepreneurs and small businesses, this ensures that great apps can be obtained cost-effectively and in accordance with any budget.

Building cross-functionality apps

Android and iOS are the two biggest mobile platforms, which means most companies want to have an app that is available on both types of devices. Traditionally, this meant developing two apps to cater to the varying platforms. With React Native, however, apps can be developed for Android and iOS simultaneously. When using React Native to build an app, most of the code can be shared between these two platforms, which means only minor changes need to be made to reflect which platform it will be used on. For developers, this means faster mobile app development, and, for businesses, this means reduced mobile app development costs and increased turnaround times.

API Rendering

Although there are other cross-platform development applications out there, most of them rely on rendering via webviews. This differentiates apps and sets them apart from native mobile applications, particularly because it often prevents the app from accessing the platform’s native UI elements. However, React Native doesn’t work in the same way. Instead of restricting rendering the webviews, React Native uses the host’s standard rendering APIs. Mobile apps developed with React Native will not only perform in the same way as native apps they will also have access to the platform’s native UI elements, ensuring better functionality and UX experience.

Access to platform features

Whilst native apps usually have access to platform features, such as phone cameras, location services, etc., mobile apps built within applications typically do not. Clearly, this limits the capability of the app and prevents it from being as functional as you would like. With React Native, however, you get all the benefits of developing an app within an application, without the limitations. As React Native discloses JavaScript interfaces for the platform’s APIs, apps built with React Native can access the platform’s features.

Ultimately, React Native allows for faster mobile app development and increases the functionality of apps. Giving developers the scope to build mobile apps in languages and frameworks they’re already familiar with, it has opened the door to a flurry of new mobile app developers and ensured that brands can create functional, budget-friendly and user-friendly mobile apps.

Originally published at https://www.syntx.io on August 12, 2019.

Advantages of React Native was originally published in Syntx — News, Blog & Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

B.N. (Before Node)

For most of software engineering history, JavaScript has been a language with limited functionality because of the simple fact that it could only run in the browser. Each browser has an engine that enables JavaScript to run, such as the Mozilla Foundation’s Rhino, or Internet Explorer’s Chakra. These engines, along with certain unique functionality, made JavaScript a powerful choice for the front-ends of applications, but impossible to use on the back-end. Its in-browser limitation meant that it could not be run locally, and could not be used to build a server.

Chrome’s V8 JavaScript Engine

In 2008, software engineers and internet users everywhere received an incredible gift from Google: the Chrome browser. In September of that year, Google launched both the Chrome browser and the V8 JavaScript engine on which it was built (the engine was written in C++). The V8 engine has proved to be arguably the fastest and most powerful JavaScript engine available, and its open-source status has allowed other developers access to it from a development standpoint.

The V8 engine offered the foundation to use JavaScript outside of the browser. Other options for server-side JavaScript had come before, but none were nearly as successful in their attempts. For those of us who have only ever known JavaScript with the availability of Node.js, we take it for granted. But at the time, this was huge. Ryan Dahl, the original developer of Node.js, saw the opportunity that the V8 engine presented and took to adding additional functionality to the open-source code. Most importantly, Node.js would come to support the creation of web servers, and introduced the event loop.

World, Meet Node.js

The first version of Node.js was launch in 2009, less than a year after Chrome was released, and included this ability to create web servers in JavaScript. In addition to allowing server creation, Node.js made it possible to run JavaScript code locally. If you have ever used IRB in Ruby, Node.js allowed for the same ability to run code in your terminal that IRB does.

While Netscape’s LiveWire, the first attempt at using JavaScript for server-side programming, never really took off, Node.js did not share this struggle. Having been built on the powerful V8 engine and been released at a time that the JavaScript language was already gaining in popularity, the Node.js runtime environment exploded and has not slowed down since.

To be clear, yes, Node.js is a runtime environment. It is not a framework, a library, or an engine. It is a runtime environment, because it is, as this description suggests, an environment that allows for JavaScript code to run. If the V8 engine and Chrome (or Firefox, Safari, etc.) create the environment that allows JavaScript to run in browser for a user to interact with, Node.js creates the environment on the back-end for JavaScript to run.

A.N. (After Node)

Node.js opened the door to a world in which writing full-stack JavaScript was not only possible, but a fantastic option. Using one language across an entire application just makes life easier. There is more fluidity between the back-end and front-end. The whole team working on an application is writing in the same language. Front-end engineers can more easily step into back-end work when needed, and vice-versa. On top of all of this, it’s incredibly fast, and incredibly performant.

Node.js has paved the road for popular backend frameworks like Express.js, Next.js, and Meteor.js. Between Express.js and React.js, you can have a full-stack application running with only two lines in your terminal. That’s pretty amazing. And with popular NoSql database options like Mongo DB (MERN, MEAN), you can even just store data essentially in JSON format in the database. From database to user, you have consistency and know what to expect, and that is a powerful thing in software engineering.

Originally published at https://www.syntx.io on November 15, 2019.

How Node.js Transformed the Landscape of Backend Engineering was originally published in Syntx — News, Blog & Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you are looking to build an API that interacts directly with the Google Ads platform and aren’t using one of the supported client libraries provided by Google which includes Java, C#, PHP, Python, and Ruby, then this post might be helpful to you. In our case we were using Javascript, building a NodeJS backend that was required to interact with the Google Ads Platform to do various different actions for our clients, such as getting and displaying information from all their campaigns to trickier ones like adding IP Addresses to the campaign’s IP block list. We will be going over how to do all this following along with Google’s own Quickstart documentation and better explain some of the more trickier parts.

First thing’s first, make sure you have the right accounts set up to go forth with all the API calls. We want to be using Test accounts as to not mess up any production data or live ads while we are testing and developing this API.

You will need one production Manager account to get your developer token from. So go ahead and create a Manager account if you don’t have one already and head over to the Settings — API Center to get your developer token. Note: You can use this developer token to interact with any other accounts, not only your own under your account.

You will also need a Test Manager account, which can be created here. I recommend using a separate email address for all your test accounts as to not get anything confused. Create a new Gmail if you have to, it helps a lot when you are going back and forth between your test accounts and production manager account that has the developer token from above.

Next, you will need to get an access token and refresh token. This part we will not cover as you are free to use whatever client library you would like. We use React so we went with this library. Using that we were able to get refresh token given the authorization code returned after successfully logging in to our account that has the test manager account. More information on OAuth here.

Logging in to your test manager account here is important as you can only interact with test accounts until your developer token is approved.

The first API call I make tests if I’ve gotten everything set up properly, For that we use customers:listAccessibleCustomers. This call will list all the accounts you have access to work with, given your developer token and access token. From there, you can parse out the Customer ID and use that for any other calls you’d like to make.

The following cURL request will get this result. Fill in the missing variables with your own from above.

curl -X GET \ https://googleads.googleapis.com/v1/customers:listAccessibleCustomers \ -H 'Authorization: Bearer {your-access-token-here}' \ -H 'developer-token: {your-developer-token-here}'

If you received a list of your customer accounts you are on the right track. Getting a little more into it, let’s grab all the campaigns listed under one of our customer accounts. For this we are going to use this cURL request:

curl -X POST \ https://googleads.googleapis.com/v1/customers/5509440813/googleAds:search \ -H 'Authorization: Bearer {your access token here}' \ -H 'Content-Type: application/json' \ -H 'developer-token: {your developer token}' \ -H 'login-customer-id: {customer manager account id, if under a manager account}' \ -d '{ "query": "SELECT campaign.id, campaign.name, campaign.status, campaign.serving_status FROM campaign" }'

The URL the request is hitting can be hit to retrieve most of the account’s information using the correct query. Here is an overview with some information on the query language used above. The query will be somewhat familiar to you if you are used to SQL queries. The only thing is you would need to know which fields you want to access from the right resource first, otherwise, you will get a vague error. Here is a link to the reference, this provides a list of all the available resources.

Note: login-customer-id is the test customer's manager account id. If the customer you are trying to access has a manager account it is required to provide this id in the headers as done so above. For testing purposes where you can only use a test manager account, that means for every call you make basically.

If you want to interact with the campaigns you have retrieved from above, the API calls are slightly different and require you to go through each available service and its defined proto file here — linked proto file to Campaign Service, to build your desired request up. Below is an example of a request to add an IP Address to a specific campaign’s IP blocklist.

curl -X POST \https://googleads.googleapis.com/v1/customers/{CUSTOMER_ID}/campaignCriteria:mutate \ -H 'Authorization: Bearer {your access token}' \ -H 'Content-Type: application/json' \ -H 'developer-token: {your developer token}' \ -H 'login-customer-id: {manager account id, if needed}' \ -d '{ "customer_id": "{CUSTOMER ID - ex: 1234567890}", "operations": [ { "create": { "campaign": "customers/{CUSTOMER_ID}/campaigns/{CAMPAIGN_ID}", "negative": "true", "ip_block": { "ip_address": "127.0.0.1" } } } ] }

Again the documentation for these are somewhat vague and this is a very specific example but you can use this to build a request for any other service using the provided api reference and proto file, it will follow the same format.

Going over this request: URL contains the Customer ID you are calling this action on — all digits without the dashes as shown in the console. Then the JSON — Again the customer ID the same as in the URL, operations : you can see a list of available operations in the service's proto file, in our case CampaignService includes create, update, and remove. campaignin the created object refers to the campaign's resource name which follows that format. negative in this case, is there because IP Block specifically requires it. And then the criteria we are acting on which is ip_block.

Wrapping it up, the Google Ads API is a bit of a struggle to work with especially if you are trying to use REST endpoints with JSON as they are largely undocumented and a lot of the work is going from one reference to the other to piece together what you need. For me it was the IP Blocking, I hope this provides some clarity for some people and puts them on the right track to do what they need with the Google Ads API.

When in doubt, the Google Ads API forum is actually pretty active with knowledgeable members of the team responding to most everyone’s questions in a day or two(in my experience). There is also a good amount of info already on there for some specific use cases.

Originally published at https://www.syntx.io on June 28, 2019.

Using Google Ads API with REST endpoints was originally published in Syntx — News, Blog & Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

Cookies, not the yummy chocolate ones but the old way to authenticate users, are still heavily used. Unfortunately, React Native has some trouble when it comes to native cookie management.

Normally you can easily add:

{ withCredentials: true }

This automatically adds the cookie to each request and you technically don’t have to worry about anything. As mentioned above, this doesn’t work 100% of the time to React Native.

Furthermore, you might want to use the cookie value and persist in localStorage meaning the actual device.

That by itself can be easily archived be accessing the Header values when requesting the cookie and storing that Cookie. From here, you just have to add the Cookie to the Header when making a request that requires the Cookie value:

{ Headers: { Cookie: "CookieValue" } }

After a while and making various requests back and forth you might notice some inconsistent behavior here too. The reason for that is the Network Handler. It might request a new Cookie and it will conflict with the Cookie you are manually setting. We have tried various ways to block/avoid this behavior but nothing has helped.

We ended up with the following solution: We clear the cookies manually after each request to make sure the RTCNetworking module doesn’t store any Cookies without our knowledge:

const RCTNetworking = require('RCTNetworking'); export default function clearCookies() { return new Promise(success => { RCTNetworking.clearCookies(success); }); }

Last but not least, you might leverage native web views. If you do, you have to make sure to clear those cookies manually as well because the cookie management in the native environment (I.e. iOS) is separate from the cookie management in JavaScript.

let cookieStorage = HTTPCookieStorage.shared if let cookies = cookieStorage.cookies { let tedCookies = cookies.filter{ $0.domain.contains("domain.com") } for cookie in tedCookies { cookieStorage.deleteCookie(cookie) } }

By manually clearing the cookies you can be 100% sure that no other cookies will interfere with your manual management.

Btw. This method doesn’t require you to use any 3rd party cookie management libraries.

Originally published at https://www.syntx.io on April 18, 2019.

Cookie Management in React Native was originally published in Syntx — News, Blog & Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

Syntx Receives Another Perfect 5.0 Star Review on Clutch!

Syntx is a refreshing change. We understand business realities and appreciate the value of transparency amidst a complicated and constantly evolving industry. We are a knowledgeable partner when it comes to software development and UI, and we are truly passionate about results from a straightforward process that consistently yields success. Before designing custom solutions for each client, we begin with a discovery phase, suggest a proposal, provide frequent updates through development, and monitor results with big data analytics. Our open and honest communication has made us create trustworthy and profitable relationships with clients, and we are happy to share that our clients have once again recognized our services with a Clutch review.

One of our clients, Munch Citi, was gracious enough to share their experience working with Syntx on Clutch. We were hired to design an app for a food truck tracking startup that locates street food vendors open at a certain time. Additionally, we designed a logo and provided blueprints that were highly attractive when pitched to local food truck vendors to gain interest in participation.

In the review, we were praised for our responsiveness and willingness to communicate during any hours of the day, in order to get the client what they need. We are appreciated for our focus on clients and the ability to customize services towards each project’s needs. Clutch evaluates companies based on several metrics, including meeting deadlines, quality of service and deliverables, cost value, and likelihood to refer in the future. According to Munch Citi, we are deserving of a perfect 5.0 Star review in all four categories.

We are extraordinarily proud of the services that we provide to clients, but it does not come without hard work and commitment. We take our time to deliver the highest quality deliverables, and it’s an honor to receive such glowing reviews. In the words of Munch Citi’s CEO:

“When it comes to Syntx, their work is amazing, but they’re humble when they talk about it. They just want to focus on the project itself, and they treat million-dollar and thousand-dollar clients the same.”

Not only can you see ratings and reviews for Syntx on Clutch, but its affiliate site, The Manifest, also includes company rankings and identifies top-performing businesses. In a more article-based reviewing format, clients have distinguished Syntx as one of the top 30+ mobile app developers in Los Angeles.

We are very grateful for our positive client feedback which inspires us to continue to deliver the best client experience possible. If you want to get on board with a team with easy communication, seamless UI transition, and transparent management, please let us know!

Originally published at https://www.syntx.io on February 25, 2020.

Syntx Receives Another Perfect 5.0 Star Review on Clutch! — Syntx | Before we build. We Listen. was originally published in Syntx — News, Blog & Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

We are very proud to announce that Syntx was awarded as Los Angeles Clutch Leaders in 2019. We got awarded in the following categories:

• Web Development
• Mobile App Development
• Software Development

“Receiving this award in our first year of business is a huge accomplishment for all of us! It shows that we understand our clients and deliver great solutions. We are truly honored to receive this award and can’t wait for what’s next.”

JP Wallhorn | Founder & CEO at Syntx

At this point, we want to thank all of our clients who have trusted us with their projects and products and of course our team who has been working very hard making this dream come true.

We are highly motivated to keep growing and we are truly excited to share upcoming projects with you. Over the last couple of months, we’ve been helping other entrepreneurs to build amazing products.

Furthermore, we have more exciting news that we are working on and can’t wait to share them with you!

Sign up for our newsletter!

© Syntx.io | Better-Built React Solutions | Consulting with success guarantee

Los Angeles Clutch Leader 2019 was originally published in Syntx — News, Blog & Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

Salesforce DX is the new development environment that will eventually replace the Salesforce EDI that’s based on Eclipse. Recently, Salesforce announced that they won’t release any new feature for the Salesforce EDI any longer. While they will still support it until October 12th, 2019 all new features will be released for Salesforce DX.

On Oct. 12th, 2019 we will no longer provide support or updates of any kind to the Force.com IDE.

Having said that, Salesforce DX stands for Salesforce Developer Experience and just follows the trend that Salesforce has chosen for its platform. Rather than being exclusive and very separated with they want to stay up to date with the latest trends and development environments. Before, you had to choose between the built-in Developer Console or Salesforce EDI. Both weren’t ideal and very outdated compared to other solutions. Yes, there are 3rd party solutions such as Welkin Suite that leverage the Salesforce API but I wasn’t convinced that any of those were really 100% as good as my JavaScript Development environment for example.

Salesforce DX takes advantage of the very popular open source editor Visual Studio Code and has published all its add-on exclusively for that platform (as of right now). Therefore, if you want to develop there are a couple of add-ons that are required to use Visual Studio Code for Salesforce Development. They offer APEX syntax support and various API integration to manage your projects.

Additionally, Salesforce wants to make sure that you integrate your development efforts with Git, specifically GitHub. That allows you to keep track of any changes in your code and traceback code snippets to a specific point of time and developer. If you are familiar with GitHub, you are most likely familiar with the concept of branches and pull-requests that allow you to develop various features simultaneously without affecting the main (master branch) code. From there, you can deploy those versions on separate instances and test those accordingly.

Salesforce allows a very similar behavior by allowing developers to leverage Scratch Orgs. You are already familiar with Sandboxes, which are used for development and testing purposes. A Scratch Org is basically a developer environment that allows developers to easily push and pull the code that lies in separates branches. Therefore, it can be developed independently before releasing for testing. Additionally, the newly released Salesforce CLI allows you to manage those scratch orgs and log in from the terminal. That makes managing your credentials 10x easier. Once it’s set up, you are able to push and pull code as well as a login at any point of time without remembering your login for that specific org.

We truly believe that Salesforce DX is a brilliant move in the right direction for Salesforce and demonstrates the wisdom of Salesforce’s direction.

Getting started with Salesforce DX

Before you can start with Salesforce DX, you to enable the Development Hub for the organization you are working in. That’s amiable under the regular Setup and can easily be enabled with a click of a button.

From there, you have to install the Salesforce CLI. You can install it via a package (click here) or npm (click here). For npm enter the following in your terminal:

npm install sfdx-cli --global

Now that you have installed the Salesforce CLI you can take advantage of the following commands:

Additionally, you can look up the official documentation as well right here or run:

sfdx force:doc:commands:list

At any given time, you can easily add — help to get some guidance in regards to what options are available. Especially, in the beginning, you will find this particularly useful because there are so many CLI commands.

From here, you create a new folder that will store & manage all your source code.

To get started, you have to maintain your Salesforce connections. I started with my production environment to get the initial status quo and all dependencies that are required to do actual development through Salesforce DX going forward.

sfdx force:auth:web:login --setalias my-hub-org --instanceurl url

Retrieving & Converting Salesforce Code

Having the correct origination connected to your CLI brings you to the next step before you can start your development.

In the Setup, create a new package and include all dependencies and custom fields that are required for a copy of your current organizations. This is required when you want to create your Scratch Org later since Scratch Orgs do not include all the customizations you have done your system. That is also the first major difference to a regular sandbox that normally includes all customization you have applied to your Salesforce environment.

Since no customizations are included, please make sure to include all managed packages from the App Exchange in your dependencies as well. Otherwise, you will run into errors since those are not included automatically.

Once you have created your package, release it, download the full content and unzip it. This will allow you to convert it into a Salesforce DX project.

sfdx force:mdapi:retrieve -s -r ./mdapipkg -u [your_username] -p
unzip ./mdapipkg/unpackaged.zip -d ./mdapipkg/

Now that you have bundled up, all of your customizations and exported it, just run the following command in the Salesforce CLI and it will be converted into a Salesforce DX compatible project that you can use for further development.

sfdx force:mdapi:convert -r ./mdapipkg

Scratch Orgs

Let’s catch up. We installed the Salesforce CLI, connected to your preferred Salesforce organization, bundled up all customizations, defined dependencies and converted them all into Salesforce DX compatible project.

Pretty cool — so far it seems pretty extensive to work with Salesforce DX but I promise that once you have completed this setup, it will get a lot easier and you will appreciate the ease of Salesforce DX (Once again, if you are coming from a JavasScript development world i.e. this will still look crazy to you :))

Set up a new scratch org and upload your complete project. This will pretty much create a Developer Sandbox. Now you can easily, modify existing code and add new functionalities. Additionally, everything from here on works with the typical git push/pull structure.

sfdx force:org:create -f project-scratch-def.json -a [ScratchOrgName]

To push your Salesforce DX package into the newly created Scratch Org you can use the regular push command:

sfdx force:source:push -u [ScratchOrgName]

VERY IMPORTANT WHILE YOU DEVELOP

I got stuck, wondering why my latest changes didn’t make it into the scratch org for at least 30 minutes.

Let’s say you run into an error that you are using a custom field that doesn’t exist yet but you just skipped over the error message. Unless you modify the file and push it again it won’t show you the error message again. Having said that, it’s very important to read ALL error messages if there are any while you are pushing up your changes. A lot of times, I had the toughest time finding out what was going on and why my modified files weren’t pushed up into the org.

Reason for that was an error that was just getting ignored when trying to push again without modifying the actual file. I think that’s a flaw in the current version and will hopefully be something that they will improve going forward.

Sign up for our newsletter!

© Syntx.io | Better-Built React Solutions | Consulting with success guarantee

Getting Started with Salesforce DX was originally published in Syntx — News, Blog & Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.