Appbase.io

appbaseio

This blog post will help you build powerful search UI experiences similar to Airbnb's. I will do this using ReactiveSearch - the most popular React UI components library for building search interfaces. I will do this by breaking down the UI into components so this will be helpful to build any search UI. In the process, you will also learn about about how to work with ElasticSearch. . You can read all about it . If you have already worked with an earlier version ReactiveSearch, this post will also guide you wrt the breaking changes for v3 and how you can upgrade your components. ReactiveSearch v3 is just out now here You should try out the to see what we will be building. I will wait for you! Live Demo of our final app here What is ElasticSearch and why should you care about it? Now, let’s understand the role of ElasticSearch in helping us build the above UI. ElasticSearch is a . It allows you to , , and big volumes of data quickly (we are talking milliseconds here). It is generally used as the underlying engine/technology that powers applications that have complex search features and requirements. You can read more about it . super-fast, open-source, full-text search engine store search analyse here With ElasticSearch, you can build a fast search utilising its powerful Query DSL. However, setting up ElasticSearch correctly requires a lot of work. For instance, the data mapping, analysers and tokenisers need to be set correctly or you may not receive accurate search results back. Besides, the more filters that get applied along with the search query, the more complex the resulting search query becomes. We, at Appbase, have built some open-source tools to help you do all these things with the matter of some clicks. A tool to into ElasticSearch — add data Importer A tool to like an excel sheet — view ElasticSearch data Data Browser A tool to easily — generate relevant ElasticSearch queries Query Builder In this blog post, with the help of some of these tooling, we will utilise the strengths of ElasticSearch with React to build powerful apps. How to use ElasticSearch with React? We will be using and open-source libraries to build the Airbeds app in this post. These libraries offer a range of highly customisable rich UI components that can connect with any ElasticSearch server and provide you with an appropriate default search query for all generic use-cases (like E-commerce, Yelp, Meetups, etc) bundled into these components. ReactiveSearch will help us to build UI widgets for filters and search-related UI elements. ReactiveMaps will provide us with the UI widgets for Map related UI elements. ReactiveSearch ReactiveMaps is currently featured on Product Hunt. 🎉 🎉 ReactiveMaps A sneak peeks into the UI components offered by ReactiveSearch and ReactiveMaps. Image: Things we will need In order to build Airbeds application, we will need a set of things before we get started with writing actual code: Dataset for Airbeds App: To make a great UI we should have a good dataset. We found an awesome dataset for our App. Here is the link to a dataset: . https://www.kaggle.com/airbnb/seattle ElasticSearch hosting: You can set up and install an ElasticSearch server by following the , or you can create a free account at which provides ElasticSearch hosting as a service and is easy to use. For simplicity, we will be using appbase.io service to get started. official installation guide appbase.io I’ve already created an appbase app with Airbeds dataset. You can check out the cleaned-up dataset from above , which is built by Appbase.io: over here in the data browser tool Dejavu Hosted ElasticSearch dataset for our app. View Image: here The credentials for accessing the above app programmatically are: app= credentials= "airbeds-test-app" "X8RsOu0Lp:9b4fe1a4-58c6-4089-a042-505d86d9da30" // read-only Now, we will go step by step to build our application. We’ll use . So, you can be with me during the whole journey and see the step by step progress of our application as we build it. Click on the above link and click on Open React button. Codesandbox.io Step 1: Base setup for CRA with ReactiveSearch and ReactiveMaps If you have tried out the before, you will feel right at home as we build this app. Create React App Create React App Initialise the CRA setup. We will use npm as the package manager, you can also use yarn instead. npx create-react-app airbeds
cd airbeds
npm start Note: npx comes with npm 5.2+ and higher, see instructions for an older release here Go grab a coffee and be back in a couple of minutes … The setup will be ready for you! One of the great benefits of using CRA is that it works without requiring to set up a build configuration. At this point, you should have a directory structure similar to this: airbeds
├── README.md
├── node_modules
├── package.json
├── .gitignore
├── package-lock.json
├── public
│   └── favicon.ico
│   └── index.html
│   └── manifest.json
└── src
    └── App.css
    └── App.js
    └── App.test.js
    └── index.css
    └── index.js
    └── logo.svg
    └── registerServiceWorker.js Next, we will install the and npm packages. ReactiveSearch ReactiveMaps Install ReactiveSearch npm install @appbaseio/reactivesearch Install ReactiveMaps npm install @appbaseio/reactivemaps Use the button switch and hamburger icon to browse the code we have written so far. Snippet: Codesandbox link: 1 https://codesandbox.io/s/github/appbaseio-apps/Airbeds-app/tree/step In addition to the code sandbox above, you can also try the code so far directly from our GitHub — . https://github.com/appbaseio-apps/Airbeds-app/tree/step1 Step 2: Adding components from ReactiveSearch library Adding the first ReactiveSearch component: ReactiveBase All the ReactiveSearch components are wrapped inside a container component — ReactiveBase which glues the ElasticSearch index and the ReactiveSearch components together. We’ll use this in /src/App.js: The app and credentials are taken from my appbase.io app. You can create your own app and add those from your . dashboard We can set our app’s theme by providing the theme attribute prop to our ReactiveBase component. Here is the theme for our app: Now let’s start the server with npm start. Breaking Down The Airbeds App Now that we have a dataset to play around with and we are also done with our setup, it’s time for adding components in our app. Before you add the below snippets to the render() method, you should also remember to import them using the following format: { Component# , Component# } @appbaseio/reactivesearch import 1 2 from 1. DataSearch Component component creates a search bar UI which allows us to search for available rooms. DataSearch In this component, we are passing the dataField parameter with the name value. Here, name is the column in the database on which we want to apply our search. You can learn more about this component . here 2: RangeSlider Component will be used to create the price filter which allows a user to filter accommodations based on their budgets. RangeSlider In this component, we are passing the range attribute, which will define the start and end value of our filter. We can set the labels with rangeLabels parameter. We have set default values of start and end price as 10$ and 20$ respectively. range parameter shows the list of components, with RangeSlider component has to change reactively. You can learn more about this component . here 3: NumberBox Component will help us to make UI widget for Guests filter, which allows a user to filter properties by the number of guests that can be accommodated. NumberBox Here, data parameter defines the maximum and minimum value for the NumberBox component. You can learn more about this component . here 4. DateRange Component will provide UI widget for Date filter, which allows a user to select a range of dates for accommodation. DateRange Here, the numberOfMonths attribute shows the number of months to be shown in the calendar view. initialMonth sets the initial visible month when the calendar UI is opened. You can learn more about this component . here Codesandbox link: 2 https://codesandbox.io/s/github/appbaseio-apps/Airbeds-app/tree/step In addition to the code sandbox above, you can also try the code so far directly from our GitHub project — . https://github.com/appbaseio-apps/Airbeds-app/tree/step2 Step 3: Styling the components we have so far Alright, Alright, Alright !!! I got it! You must be thinking that why these components look so simple. Let’s add some styles to them. We are using the majority of styling for setting layout. We have used flex to design our layout. We have used buttons for each filter. We will show particular filters when the user hovers on particular buttons. Add styles in App.css file and add this statement in App.js file: ; import "./App.css" Use the button switch and hamburger icon to browse the code we have written so far. Snippet: Codesandbox link: 3 https://codesandbox.io/s/github/appbaseio-apps/Airbeds-app/tree/step In addition to the code sandbox above, you can also try the code so far directly from our GitHub — . https://github.com/appbaseio-apps/Airbeds-app/tree/step3 Step 4: Adding components from ReactiveMaps and styling them We will import components from ReactiveMaps library using this statement: { ReactiveGoogleMap } ; import from '@appbaseio/reactivemaps' 5. ReactiveGoogleMap Component component provides a map as a data-driven layer. One can add marker pins, show popovers, draw polygons, build navigation routes based on the results from the ReactiveSearch components. In our current app, we will display the available accommodations based on the search and filters onto the map view. Interesting! Isn’t it? ReactiveGoogleMap In this component, defaultZoom attribute defines the map’s zoom level and accepts integer values between [0, 20]. We can also provide style to ReactiveMap component with the style prop. The innerClass attribute helps us to provide className for inner components of ReactiveMap. renderAllData attribute is used for showing result cards for user’s search. We have designed our result-cards using flex. We will show markers on the map with using renderData parameter. You can know more about this component . here Wohoo!!! We have made working Airbeds app! But still, we will add more styles to make it look cooler and professional! Use the button switch and hamburger icon to browse the code we have written so far. Snippet: Codesandbox link: 4 https://codesandbox.io/s/github/appbaseio-apps/Airbeds-app/tree/step In addition to the code sandbox above, you can also try the code so far directly from our GitHub — . https://github.com/appbaseio-apps/Airbeds-app/tree/step4 Adding the popover effect on markers Now in the final step #5, we will add a popover effect on markers so that when a user clicks on the marker, we can show them more details. Let’s do it! We will use onPopoverClick attribute of ReactiveGoogleMap component to achieve this. The return value here is a valid JSX markup, giving you full control over what can be displayed within it. This is how my onPopoverClick function looks: Congrats! If you have followed along so far, you should see a fully working Airbeds app, just as you saw at the start of the post! 🎉 Use the button switch and hamburger icon to browse the code we have written so far. Snippet: Codesandbox link: 5 https://codesandbox.io/s/github/appbaseio-apps/Airbeds-app/tree/step In addition to the code sandbox above, you can also try the code so far directly from our GitHub — . https://github.com/appbaseio-apps/Airbeds-app/tree/step5 In case you are missing a step, you can get the code so far by following these: git clone https: cd airbeds
npm install
npm run dev
# open http: //github.com/appbaseio-apps/Airbeds-app.git //localhost:3000 Summary Here comes the end of our journey, and we have got our awesome Airbeds app built with ReactiveSearch and ReactiveMaps. To summarise everything so far: This post introduces and — UI components libraries for ElasticSearch that provide the scaffolding for building great search experiences. Next, we went step-by-step to add different UI components and style our app. ReactiveSearch ReactiveMaps : Base setup for CRA with ReactiveSearch and ReactiveMaps ( ) Step 1 Codesandbox link : Adding components from ReactiveSearch library ( ) Step 2 Codesandbox link : Styling the components we have so far ( ) Step 3 Codesandbox link : Adding components from ReactiveMaps and styling them ( ) Step 4 Codesandbox link : Adding a popover effect on markers ( ) Step 5 Codesandbox link Useful References: While this post only shows how to build an Airbnb like search, we offer a 5+ hours course teaching on how to build an end-to-end Airbnb clone using React, Redux, TypeScript, Express.JS, ElasticSearch, Firebase and Postgres SQL: . https://reactiveapps.io/products/AWtRe_43OSQtLugWf1Fk All ReactiveSearch and ReactiveMaps components can be interactively tried using the playground . https://opensource.appbase.io/playground/ The documentation for all the above plus 20 other components is available at . https://docs.appbase.io/docs/reactivesearch/v3/overview/quickstart/ You can look at the code for this app at . https://github.com/appbaseio-apps/Airbeds-app Finally, go ★ the project on so you can find it when you need to build that awesome search! Github

How to Build an Airbnb clone with React and ElasticSearch

We will go over the process of building a starter e-commerce mobile app for searching through a books datastore using React native. If you have never worked with React Native before, this can act as a kickstart to your mobile app development journey with Javascript! 🎉 Some context first! It’s 2018 and JavaScript is growing faster than ever before. The entire community has been working hard to make the web more and more accessible. Everything starting from the libraries and frameworks, to the dev tools required to build the apps, have matured gracefully. Sure, there has been some chaos amidst these improvements. But it is just fascinating that if you know JS today, you can build a web app, a backend server and even mobile apps. React Native enables building native mobile apps using JavaScript and React. Unlike Cordova/Ionic/Phonegap that also lets you build mobile apps using JavaScript with WebViews, React Native compiles entirely to a native app and also allows writing native (Swift, Objective-C, Android) code when required. Things you need to know before getting started 👶 You should have some (if not much) experience writing React. It is fairly easy to get started with and has that can help. If you are new to the subject, you can . And, if you prefer videos over text, I highly recommend ’s free course on Egghead — . good resources available online start with the official tutorial Kent C. Dodds The Beginner’s Guide to ReactJS It’d be best if you have a fair understanding of ES6+ as well. I’ve got you covered with that. I wrote a which should put you on track in no time. 💪 kickstarter guide to writing ES6 You don’t necessarily have to spend a lot of time learning react and building web apps. . But if you quickly want to get started with React Native, get yourself familiarised with React’s basic fundamentals because React Native and React share the same core principles for building apps. They just target two different clients — web and native. (Although I’d recommend you to do that) Here, I want to highlight the fact that if you use React and React Native in production, you can end up with a lot of shared code across all the platforms (web, iOS and Android). This will enable you to maintain bigger projects with less development time and costs 😉. This is one of the reasons why React Native is starting to see industry wide adoption: Airbnb, Facebook, Instagram, Walmart, Tesla have their mobile apps built using RN. Basic Concepts 👩‍🎓 Let’s start by briefly discussing how React Native works and how the JavaScript code actually translates into a kickass native mobile app. Any React Native application runs in two threads: 1. Main thread This thread manages the user interface of your app and processes all the native interactions including gestures and touch. Since React Native also allows you to add in native code written in Android Java, Objective C or Swift, these chunks of code get executed on this thread. 2. JavaScript thread This executes the JavaScript code that you write in a separate (which is present in iOS by default and gets shipped to Android devices with the build). JavaScript engine For the application to work, these two threads need to talk to each other, which is what is for. Bridge React Native core architecture Bridge, as the name suggests, helps in the data (message) transactions between the JavaScript thread and the Main Native thread. These messages can be asynchronous or batched. Bridge enables one’s JavaScript code to talk to the native modules and interact with the device APIs. Now that we have the basic understanding of react native architecture, let’s get into the implementation details. Setting up the development environment 💻 If you already have React Native installed and are familiar with the development ecosystem, you can skip ahead to the next section . For those of you, who are just getting started, you can either (which is more detailed), or follow along with me here: follow the official setup guide here Make sure you have installed in your system. node We will be using the create-react-native-app (CRNA) tool for setting up the boilerplate. npm install -g create-react-native-app Then run the following commands to create a new React Native project, say HelloNative: create-react-native-app HelloNative

cd HelloNative
npm start This will start a development server for you, and print a QR code in your terminal. The only caveat of using here is that it may not use the latest version of react-native. If that bothers you, you can use or which are also fairly simple to get started with. create-react-native-app Expo CLI Expo XDE Next step is to install the client app on your iOS or Android phone and connect to the same wireless network as your computer. Using the Expo app, you can scan the above generated QR code from your terminal and open your project directly in your phone. How cool is that! Expo At this point, your app should look like this: React Native app If you wish to run this app on an emulator, you can run: npm run ios for iOS and, npm run android for Android emulator. This will install Expo client on the emulator and run your react-native app. If you now open the developer menu in the app, you’d see options to enable . These allow you to reload your app instantly, which is a major advantage if you come from Android development background where it takes ages for gradle to finish building. Hot Reloading and Live Reload A closer look at the developer options The developer options come bundled with debugging features as well. We will get into the details of it in the next section. Debugging and troubleshooting ⚒ Debugging Remote JS feature in the developer menu allows us to browse through any console messages or errors in the browser. This comes super handy while you’re building apps. Additionally, you may want to install while you’re at it. React Native debugger React Native Debugger in action This is a nifty tool that allows us to browse through the component state and props tree in React Native apps. It also enables you to browse and edit the styles that are being applied to the components present in your app, serving as a replacement for chrome-dev-tools here. 🔋 Batteries included React Native comes with a range of built-in components that you can use to build apps with. You can browse through the where in you will find some of these components to be platform specific — under and sections. list of available components here Android specific iOS specific These components will help you put together simple UIs for your app. Similar to web, React Native supports fetch enabling you to make http requests and get data from your server. For our 📗 booksearch app, we will be using Elasticsearch, which is a database which can search through large amounts of data in a short time. It performs a on the data which is stored in the form of documents (which are JSON objects) by examining all the words in every document. NoSQL full-text search Even if you’ve never used Elasticsearch before, you should be able to follow along with this tutorial. Elasticsearch may not seem like an easy thing to get started with. The setup, adding or viewing data and generating query can seem a bit overwhelming if you are a beginner. That’s why, we, at , have built some open-source tools to help you do all these things with the matter of some clicks 😉 Appbase Tool to into Elasticsearch — 🗃 add data Importer Tool to like an excel sheet — 👀 view Elasticsearch data Data Browser Tool to — 🔨 generate relevant Elasticsearch queries Query Builder In this blog post, with the help of some of these tooling, we will utilize the strengths of Elasticsearch ⚡️ with React Native to build a rich mobile bookstore app. You can set up and install an Elasticsearch server by following the , or you can create a free account at which provides Elasticsearch hosting as a service and is easy to use. For simplicity, we will be using appbase.io service to get started with. official installation guide appbase.io I’ve already created an appbase app with books dataset for simplicity. You can check out the dataset . over here Dataset of books You can clone this dataset and generate credentials for your very own app by clicking on the button on the bottom left. Clone this app These credentials will be used to connect our UI with this app. The credentials of the above app which we will be using in this tutorial are: {
    app: "good-books-ds",
    credentials: "nY6NNTZZ6:27b76b9f-18ea-456c-bc5e-3a5263ebc63d",
    type: "good-books-ds"
} Say hello 👋 to Reactivesearch 🔍 We will be using , an open-source React and React Native UI components library for Elasticsearch that I am a contributor to. It offers a range of highly customizable rich UI components that can connect with any Elasticsearch server and provide you an appropriate default configuration for all generic use-cases (like E-commerce, Yelp, Meetups, etc) bundled into these components. ReactiveSearch Wait, why do I need ReactiveSearch now? ReactiveSearch simplifies the entire process of connecting to an Elasticsearch index, making queries, fetching and rendering results in sleek UI, not just that, it also lets you make your components talk to each other, i.e. if Component-A gets updated, Component-B gets to know and it can update itself without needing any manual interaction. This whole component-to-component subscription comes in handy when you have dynamic filters present on your screen, such as in case of e-commerce apps where Selecting a category of Appliances, also changes the sub-categories available, their prices and what not. ReactiveSearch helps you create significantly smarter apps easily and in a declarative fashion. Reactivesearch-native bundles a range of native UI components that enables you to build UIs like Airbnb, meetups, etc seamlessly. You can find . the complete list of available components here Reactivesearch Native Components Building the 📚 BookSearch app First things first, we need to install reactivesearch-native in our React Native project by running: npm install @appbaseio/reactivesearch-native All the ReactiveSearch components are wrapped around a container component called which connects our UI components with the Elasticsearch cluster. ReactiveBase We’ll use this in App.js: <a href="https://medium.com/media/55d535313eb058b6718f539b3c1a050b/href">https://medium.com/media/55d535313eb058b6718f539b3c1a050b/href</a> Notice how we have used Flex based styling here. Styling in React Native is very much similar to that of web. If you’ve no experience using flex, I highly recommend to begin with. FlexBox Froggy Besides , we have used two other components from React Native in our code snippet: Stylesheet - This is similar to a div html element in React Native ecosystem. It is a container that supports layout with , , , and controls. View flexbox style some touch handling accessibility - This is a simple native component for displaying text. You can read more about it . Text here For our BookSearch app, we will need two components from reactivesearch-native in our layout: 1. Search box for searching the books: Here, we will use DataSearch component from reactivesearch-native. It creates a search UI component and enables us to search across one or more fields in our dataset easily. It looks like this: <DataSearch
    componentId="searchbox"
    dataField={[
        'original_title',
        'original_title.search',
        'authors',
        'authors.search',
    ]}
    placeholder="Search for books"
    autosuggest={false}
/> This component queries on the given dataField(s) in the dataset. This component goes inside the ReactiveBase component and receives all the necessary data from it so we don’t have to write Elasticsearch queries ourselves. DataSearch Notice how we have used .search fields in our dataField prop here. authors.search is a of the authors field. Elasticsearch can index the same data in different ways for different purposes, which we can use to get better search results. multi-field 2. Result List View for displaying the search results: For displaying results, we will be using ReactiveList component from reactivesearch-native. Here’s what it looks like: <ReactiveList
    componentId="results"
    dataField="original_title"
    size={7}
    showResultStats={false}
    pagination={true}
    react={{
        and: "searchbox"
    }}
    onData={(res) => (
        <View style={styles.result}>
        <Image source={{ uri: res.image }} style={styles.image} />
        <View style={styles.item}>
            <Text style={styles.title}>{res.original_title}</Text>
            <Text>{res.authors}</Text>
        </View>
        </View>
    )}
/> Here’s how its props work: dataField: orders the results using name field here. react: specifies that it should construct a query based on the current selected values of searchbox component. Every time the user changes the input value in the searchbox, a new query is fired — you don’t need to write a manual query for any of the UI components here, they are preset with a default config to meet all the generic use-cases, but if you wish, you can override it via customQuery prop. onData: accepts a function which should return a valid representing a list-item in the result list. This prop will be used to render the list of results. JSX You can read all about its prop usage . here Reactivesearch is built on top of 💯 which uses some fonts which can be included by adding: native-base async componentWillMount() {
  await Expo.Font.loadAsync({
    Roboto: require('native-base/Fonts/Roboto.ttf'),
    Roboto_medium: require('native-base/Fonts/Roboto_medium.ttf'),
    Ionicons: require('@expo/vector-icons/fonts/Ionicons.ttf'),
  });
} With these components and some styling 💅 magic, here’s what our app looks like: <a href="https://medium.com/media/06df7e2c65eaab585b9926f47476e671/href">https://medium.com/media/06df7e2c65eaab585b9926f47476e671/href</a> Voila! You‘ve a BookSearch app that runs on Android & iOS If you wish to play around with this app on the fly, 🎉 try this snack here Useful links 🌟 ReactiveSearch GitHub repo ReactiveSearch docs Hope you enjoyed this tutorial. If you have any thoughts or suggestions, please let me know and do share your version of the app in the comments 😉

Building An E-commerce Search App with React Native 

The key components in this story: NodeJS, ReactiveSearch, React Native and Auth0 Authentication is an important concern when building apps. A common use case we come across when building apps is in order to accept only authenticated requests, hence preventing misuse. securing our API In this story, I’ll be using a and explain how to create a secure Node/Express API to handle the reate, pdate and elete operations for the app. This will let the app only allow editing of data by authenticated users. For this post we’ll assume that: Todos app built with React Native C U D All users have access to the todos. Read Only an authenticated user has write access for , and the todos. For brevity, we’ll be considering all the authenticated users to have write access. Creating Updating Deleting The key components that I will be using for the app are: a data-driven UI components library for React Native, ReactiveSearch Native , as a middleware server for authenticating the requests and doing write operations to the database , NodeJS/Express, , as a hosted authentication service, Auth0 , as a hosted database service. Appbase.io You can check out a screencast of the app . here Final app preview ReactiveSearch is an open-source React and React Native UI components library for Elasticsearch which I’ve co-authored with . It provides a variety of React Native components that can cluster. ReactiveSearch some awesome people connect to any Elasticsearch In this story I’ll be expanding on another story I wrote on which you may check out if you’re interested in building the starter project which I’ll be using here. How to build a real-time todo app with React Native Getting Started We will use the as a baseline to build our authenticated Todos app. I’ve already setup starter projects which we’ll use both for client and server side. However, before we dive into the code, I’ll talk about a few concepts. Todos app built with appbase.io and ReactiveSearch Native Every Appbase app allows different sets of credentials ( and ) for . read write read and write access control In this post, we will ensure that client side app can only hold the for our appbase app and we’ll extract the logic for operations (for creating, deleting and editing todos) to a Node/Express server. This will allow us to restrict the write access only to authenticated users and also keep the safe. read credentials write write credentials All the todos will have the following structure: { "title": "Writing code", "completed": true, "createdAt": 1518766646430, "name": "divyanshu", "avatar": "https://s.gravatar.com/avatar/33ca46e56260bc7d54b2d7246f9a7052?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fdi.png"} Before we start building the UI, we’ll need a place to store our todos. For brevity, you can use which is hosted on or clone it for yourself by following and clicking on button. This will let you make a copy of the dataset as your own app. my app appbase.io this link Clone this App View my app dataset . You can also clone this to your own app here Authentication Concepts We’re using Auth0 for handling authentication which uses (JSON Web Tokens) as the access tokens. It comprises three parts , and separated by . A JWT looks like: JWT header payload signature dots(.) xxx.yyy.zzz The header(xxx) defines the type of token and the algorithm used for hashing. The payload(yyy) contains information about the user and additional metadata. The signature(zzz) is used to verify the sender of the token and ensure the message was not tampered along the way. You can find a more detailed explanation at the . JWT introduction guide Another popular alternative to using JWT tokens has been managing sessions. However, that introduces statefulness — JWT, being stateless, is a better approach. The access token once verified tells us that the user is authorized to access the API and forms the basis of our system. The authentication flow will look as follows: token based authentication Each request from the React app to the server will include an that will be verified on the server using Express middleware. When we signup or login via Auth0 we’ll receive an (containing user’s profile information)and an (a credential that can be used by a client to access an API). access_token id_token access_token App design We will be using , and create a new client for our tutorial app. We’ll need the and in order to configure auth0 in our app. You can get these from your Auth0 . Auth0 native Client ID Domain dashboard Getting Domain and Client Id for the app We’ll also need to add a callback URL in the section since after authentication the client is redirected back to the callback URL with the info which we’ll later parse for our use. We’ll come to this part later. Allowed Callback URLs token Adding callback URLs for the app Next we’ll need to create a new API for the identifier (a unique string value used for configuring auth0 instance in the app) which we’ll use later to verify the access tokens. audience Getting the audience identifier Diving into the code The final directory structure will look something like this: android                      // android related configsios                          // ios related configscomponents├── RootComponent.js         // Root component for our app├── MainTabNavigator.js      // Tab navigation component├── TodosScreen.js           // Renders the TodosContainer├── Header.js                // Header component├── AddTodo.js               // Add todo input├── AddTodoButton.js         // Add todo floating button├── TodoItem.js              // The todo item├── TodosContainer.js        // Todos main containerapi├── todos.js                 // APIs for performing writesconstants                    // Some constants used in the apptypes                        // Todo type to be used with prop-typesutils                        // Streaming logic goes here Here are the final repositories so you can refer to them at anytime: (i) (React Native App) Todos Auth Client (ii) (Node/Express server) Todos Auth Server 1. Getting the projects ready We are starting with the Todos app code from this and adding an authentication flow to it. You can use the following repositories as starter project files: previous post (i) Todos Native Auth Client starter project (ii) Todos Native Auth Server starter project After you’ve cloned the projects you can switch into the client project directory and test it out: npm installnpm startreact-native run-ios (or)react-native run-android This will start the Todos app (which has the entire logic on client side). Now that everything is up and running, we can start writing the authentication flow code. Note We’re using an ejected create-react-native-app template, hence the reason for using for running the app. This is needed by the package which I’m using here for authentication purposes. react-native react-native-auth0 2. Configuring Auth0 Callbacks Auth0 requires the callbacks for or which you can define in the following manner: ios android {PRODUCT_BUNDLE_IDENTIFIER}://divyanshu.auth0.com/ios/{PRODUCT_BUNDLE_IDENTIFIER}/callback and {YOUR_APP_PACKAGE_NAME}://divyanshu.auth0.com/android/{YOUR_APP_PACKAGE_NAME}/callback You can add these to your application’s callback URL via the Auth0 . dashboard For our case the package name is however you can use your own package name and update the same in android manifest and ios plist files. In the starter files I’ve already added these but if you were to do them by yourself, this is how you may done it : com.todosnative (here you can skip to the next step) You can find the file at AndroidManifest.xml /android/app/src/main/AndroidManifest.xml package="com.auth0sample" For ios, you can update the file at Info.plist /ios/todosnative/Info.plist <key>CFBundleIdentifier</key><string>com.todosnative</string> The dependency for is already present in the starter project. You can run the following command to all the native dependencies: react-native-auth0 link react-native link Next, we can update the file to have a of and add another . The file should look something like: AndroidManifest.xml launchMode singleTask intent-filter <activity    android:name=".MainActivity"    android:label="@string/app_name"    android:launchMode="singleTask"      android:configChanges="keyboard|keyboardHidden|orientation|screenSize"    android:windowSoftInputMode="adjustResize"><intent-filter>    <action android:name="android.intent.action.MAIN" />    <category android:name="android.intent.category.LAUNCHER" /></intent-filter><intent-filter>    <action android:name="android.intent.action.VIEW" />    <category android:name="android.intent.category.DEFAULT" />    <category android:name="android.intent.category.BROWSABLE" />    <data        android:host="YOUR_AUTH0_DOMAIN"        android:pathPrefix="/android/YOUR_APPLICATION_ID/callback"        android:scheme="YOUR_APPLICATION_ID" /></intent-filter></activity> You can substitute the stub values with your own auth0 domain and application id. Next, update the file and add the following: /ios/todosnative/AppDelegate.m #import <React/RCTLinkingManager.h> /* Add the following after @implementation AppDelegate */ - (BOOL)application:(UIApplication *)application openURL:(NSURL *)url  sourceApplication:(NSString *)sourceApplication annotation:(id)annotation{  return [RCTLinkingManager application:application openURL:url                      sourceApplication:sourceApplication annotation:annotation];} Next, we’ll add a in the file: CFBundleURLSchemes Info.plist <key>CFBundleURLTypes</key><array>    <dict>        <key>CFBundleTypeRole</key>        <string>None</string>        <key>CFBundleURLName</key>        <string>auth0</string>        <key>CFBundleURLSchemes</key>        <array>            <string>org.reactjs.native.example.$(PRODUCT_NAME:rfc1034identifier)</string>        </array>    </dict></array> 3. Handling authentication When you start the app from the starter project, it will look something like the following: Initial version of the app Note that initially you will not be able to add, delete or update the todo items. We’ll add the methods to handle these operations shortly. First lets add the login in . You may add the following in the function of : Button /components/TodosContainer.js render TodosContainer <ScrollView><Buttontitle="Login Button"style={{marginTop: 10,marginBottom: 10}}/>... Next, we’ll create handlers for login and logout in and pass them to the child components for use. I’ve added comments in the starter project to identify where we would need to add code. /components/RootComponent.js For authentication, I’m using . You can use your own Auth0 and here. In the method we’re saving the along with user and in state. The method will remove these from the state. All the handlers and state are passed via to the child components rendered by the component which uses from . It takes these props and makes them available under . react-native-auth0 domain clientId handleLogin accessToken avatar name handleLogout screenProps MainTabNavigator [TabNavigator](https://reactnavigation.org/docs/tab-navigator.html) react-navigation screenProps We’ll use these in : /components/TodosContainer.js Now we’ll be able to login by clicking on the login button and save the access token for use. After adding authentication Login screen after clicking on Login button 4. Passing the screenProps to Update and Delete calls in TodoItem After the authentication happens, I’m saving the , and in the state of . These are made available to the children components via by the in . In the previous step, we already passed the to the component. Next, we’ll update the component to make them pass to the API calls. accessToken avatar name /components/RootComponent screenProps TabNavigator /components/MainTabNavigator.js screenProps TodoItem 5. Handling writes So far, we have just console logged when invoking the , or calls. Next, I’ll be using three endpoints to handle writes on the data: add update delete to create todos POST / to update todos PUT / to delete todos DELETE / Here’s how we can handle these calls on the client side app. We’ll add these to : /api/todos.js One thing you’ll notice here is I’m passing some in the calls. I’m using the access token we received earlier and passing it in all the calls. We’ll use this to verify the requests on the server side. The includes the necessary data for creating, updating or deleting the todos. Also, the calls will not go through if the access token is not present. headers fetch body Now, for the final missing piece, here’s how I’m handling the requests on the server: Here the middleware verifies the access token on each request using the same which we specified on the client side and your specified here as the . If the token is absent or invalid the request will be rejected as unauthorized. Now you can fire up the server in a different terminal and you’ll be able to handle writes for your app securely. 🙂 checkJwt audience domain issuer Useful Links Todos app starter projects for and client side server side Todos app final repos for and client side server side ⭐️ ReactiveSearch GitHub repo ReactiveSearch docs Further Reading Hope you enjoyed this story. You might also like some related stories I’ve written: _A todo app touches on all the important parts of building any data-driven app, including the Create, Read, Update and…_medium.freecodecamp.org How to build a real-time todo app with React Native _Elasticsearch is one of the most popular full-text search engines which allows you to search huge volumes of data…_medium.freecodecamp.org Building a GitHub Repo Explorer with React and Elasticsearch

Securing a React Native App with Server-side Authentication

Serverless NestJS Automation on AWS Lambda

TypeORM is an Object-Relational Mapping (ORM) tool that is designed to work with TypeScript. It allows developers to interact with databases using an object-oriented syntax and supports a wide range of popular databases, including MySQL,  PostgreSQL, and SQLite. But most probably, you already know that. So the point of that article is not to explain what TypeORM is but to show some unexpected discoveries I made while working with it. Upgrading TypeORM to 0.3.11 Recently I was working on a project that uses TypeORM. The project was quite a bit outdated, and the version of TypeORM was 0.2.*. I decided to upgrade it to the latest version 0.3.11. I was expecting to find some breaking changes, and indeed they made it. Things I liked about the new version Let's say a few words about the incompatible changes I liked.
First of all of will no longer return an . Instead, these methods will return . This is a good change, is a value and having the result as means that we did something but had an empty result. , on the other hand, is a type, and it means that we did not do anything. So it is a good change. .findOne() findOneBy() undefined null null null undefined Let's look at the example: import {Entity, Column, PrimaryGeneratedColumn} from "typeorm";

@Entity()
export class User {
    @PrimaryGeneratedColumn()
    id: number;

    @Column()
    name: string;

    @Column()
    email: string;
} The old behavior: const user = await User.findOne({name: "the name we don't have in the database"});

console.log(user); // undefined Current behavior: const user = await User.findOne({name: "the name we don't have in the database"});

console.log(user); // null Things I'm OK in the new version Next, the changes in API are related to the method. The old version was more flexible and allowed to pass just parameters or the whole object. The new version requires passing the whole object. The new version is strict, and you should always pass the whole object. .find() where FindOptions FindOptions FindOptions The old behavior: const users = await User.find({
    name: "Alice"
}) The new one: const users = await User.find({
    where: {name: "Alice"}
}) Lucky for us, the new version has a new method called and will accept just parameters. .findMy() where const users = await User.findBy({
    name: "Alice"
}) Things I don't like in the new version And last but not least is the changes in handling and values of where parameters. This one came as a surprise for me as I was not able to find any information about that change in the documentation and the changelog. And actually, I stumbled upon that change only in the testing stage. In general, the application I was working on has an impressive test coverage (more than 90%), and REST API has a pretty good validation layer. So it is not easy to send a or parameter to the API. So let me get to the issue itself. null undefined null undefined Let's imagine that in some places, we don't have a proper query params validation, and we can send a or to the API. null undefined Let's have a look at the example: function findUserByEmail(email: string): Promise<User | null> {
    return User.findOneBy({
        email: email
    });
} In the perfect Typescript world, that function looks just fine, and it is not possible to directly pass or in the code - it will break the compilation. But at the end of the day, it will be compiled into JavaScript  and the resulting code will look something like this: null undefined function findUserByEmail(email) {
    return User.findOneBy({
        email: email
    });
} So it is possible to pass or to the function. null undefined findUserByEmail And now, let's have a look at the generated SQL queries for the following function calls. For the valid email parameter, both versions of TypeORM will generate the same query: select *
from
    user
where
    email = :email limit 1 I'm simplifying the query here, but the point is that the query is the same. But for the and parameters, the query in the new version will be different: null undefined select *
from
    user limit 1 So as you can see, that query will return the first user from the database. And that is not what we want. The reason for this is that TypeORM developers decided to skip the clause if the parameter is null or undefined. In the previous version, such parameters will trigger an error, and the query will not be executed. But in the new version, everything will be skipped, and the query will be executed without the clause. There is a Github issue related to that, but it looks like it is not going to be fixed soon. where where where https://github.com/typeorm/typeorm/issues/9316 So instead of waiting for the fix, I decided to write a small wrapper class to provide an additional layer of params validation. The wrapper class will check if the parameter is or and will throw an error. where where null undefined import {BaseEntity, FindOneOptions} from 'typeorm'
import {FindManyOptions} from 'typeorm/find-options/FindManyOptions'
import {FindOptionsWhere} from 'typeorm/find-options/FindOptionsWhere'

interface Constructable {
    new(...args: any[]): any
}

function paramsCheckingMixin<T extends Constructable>(base: T): T {
    return class extends base {
        /**
         * Counts entities that match given options.
         */
        static async count<T extends BaseEntity>(
            this: { new(): T } & typeof BaseEntity,
            options?: FindManyOptions<T>
        ): Promise<number> {
            await validateWhereOptions(options?.where)

            return this.getRepository<T>().count(options as FindManyOptions<BaseEntity>)
        }

        /**
         * Counts entities that match given WHERE conditions.
         */
        static async countBy<T extends BaseEntity>(
            this: { new(): T } & typeof BaseEntity,
            where: FindOptionsWhere<T>
        ): Promise<number> {
            await validateWhereOptions(where)

            return this.getRepository<T>().countBy(where as FindOptionsWhere<BaseEntity>)
        }

        /**
         * Finds entities that match given options.
         */
        static async find<T extends AppBaseEntity>(
            this: { new(): T } & typeof AppBaseEntity,
            options?: FindManyOptions<T>
        ): Promise<T[]> {
            await validateWhereOptions(options?.where)

            return this.getRepository<T>().find(options)
        }

        /**
         * Finds entities that match given WHERE conditions.
         */
        static async findBy<T extends AppBaseEntity>(
            this: { new(): T } & typeof AppBaseEntity,
            where: FindOptionsWhere<T>
        ): Promise<T[]> {
            await validateWhereOptions(where)

            return this.getRepository<T>().findBy(where)
        }

        /**
         * Finds entities that match given find options.
         * Also counts all entities that match given conditions,
         * but ignores pagination settings (from and take options).
         */
        static async findAndCount<T extends AppBaseEntity>(
            this: { new(): T } & typeof AppBaseEntity,
            options?: FindManyOptions<T>
        ): Promise<[T[], number]> {
            await validateWhereOptions(options?.where)

            return this.getRepository<T>().findAndCount(options)
        }

        /**
         * Finds entities that match given WHERE conditions.
         * Also counts all entities that match given conditions,
         * but ignores pagination settings (from and take options).
         */
        static async findAndCountBy<T extends AppBaseEntity>(
            this: { new(): T } & typeof AppBaseEntity,
            where: FindOptionsWhere<T>
        ): Promise<[T[], number]> {
            await validateWhereOptions(where)

            return this.getRepository<T>().findAndCountBy(where)
        }

        /**
         * Finds first entity that matches given conditions.
         */
        static async findOne<T extends AppBaseEntity>(
            this: { new(): T } & typeof AppBaseEntity,
            options: FindOneOptions<T>
        ): Promise<T | null> {
            await validateWhereOptions(options?.where)

            return this.getRepository<T>().findOne(options)
        }

        /**
         * Finds first entity that matches given conditions.
         */
        static async findOneBy<T extends AppBaseEntity>(
            this: { new(): T } & typeof AppBaseEntity,
            where: FindOptionsWhere<T>
        ): Promise<T | null> {
            await validateWhereOptions(where)

            return this.getRepository<T>().findOneBy(where)
        }

        /**
         * Finds first entity that matches given conditions.
         */
        static async findOneOrFail<T extends AppBaseEntity>(
            this: { new(): T } & typeof AppBaseEntity,
            options: FindOneOptions<T>
        ): Promise<T> {
            await validateWhereOptions(options?.where)

            return this.getRepository<T>().findOneOrFail(options)
        }

        /**
         * Finds first entity that matches given conditions.
         */
        static async findOneByOrFail<T extends AppBaseEntity>(
            this: { new(): T } & typeof AppBaseEntity,
            where: FindOptionsWhere<T>
        ): Promise<T> {
            await validateWhereOptions(where)

            return this.getRepository<T>().findOneByOrFail(where)
        }
    }
}

export abstract class AppBaseEntity extends paramsCheckingMixin(BaseEntity) {
}

function validateWhereOptions(where?: FindOptionsWhere<BaseEntity>[] | FindOptionsWhere<BaseEntity>): Promise<void> {
    if (!where) {
        return Promise.resolve()
    }

    if (!Array.isArray(where)) {
        where = [where]
    }
    const errors: string[] = []
    where.forEach((findOptionsWhere) => {
        for (const key in findOptionsWhere) {
            if (findOptionsWhere[key] === null || findOptionsWhere[key] === undefined) {
                errors.push(`Invalid value of where parameter ${key}`)
            }
        }
    })

    if (errors.length) {
        return Promise.reject(errors.join('. '))
    }

    return Promise.resolve()
} The wrapper class is used as a base class for all entities. Conclusion I believe that security is a very important part of any application, as we all care about our users and their data. Unfortunately, it is often overlooked, and developers don't pay enough attention to it. I hope that this article will help you to improve your application security on the database level and help you avoid some common mistakes.

Unexpected Discoveries in TypeORM 0.3.11

Do you also have old pictures of yourself or close ones that didn’t age well or that you, or your parents, took before we could produce high-quality images? I do, and I felt like those memories were damaged forever. Boy, was I wrong! This new and completely free AI model can fix most of your old pictures in a split second. It works well even with very low or high-quality inputs, which is typically quite the challenge. This week’s paper called Towards Real-World Blind Face Restoration with Generative Facial Prior tackles the photo restoration task with outstanding results. What’s even cooler is that you can try it yourself and in your preferred way. They have open-sourced their code, created a demo and online applications for you to try right now. If the results you’ve seen above aren’t convincing enough, just watch the video and let me know what you think in the comments, I know it will blow your mind! Watch the video References ►Read the full article: ►Wang, X., Li, Y., Zhang, H. and Shan, Y., 2021. Towards real-world blind face restoration with generative facial prior. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (pp. 9168-9178), ►Code: ►Use it: ►My Newsletter (A new AI application explained weekly to your emails!): https://www.louisbouchard.ai/gfp-gan/ https://arxiv.org/pdf/2101.04061.pdf https://github.com/TencentARC/GFPGAN https://app.baseten.co/applications/Q04Lz0d/operator_views/8qZG6Bg https://www.louisbouchard.ai/newsletter/ Video Transcript 0:00 do you also have old pictures of 0:01 yourself or close ones that didn't age 0:04 well or that you or your parents took 0:06 before we could produce high quality 0:08 images i do and i felt like those 0:10 memories were damaged forever boy was i 0:14 wrong this new and completely free ai 0:16 model can fix most of your old pictures 0:19 in a split second it works well even 0:21 with very low or high quality inputs 0:23 which is typically quite the challenge 0:26 this week's paper called two words real 0:28 world blind face restoration with 0:30 generative facial prior tackles the 0:33 photo restoration task with outstanding 0:35 results what's even cooler is that you 0:37 can try it yourself in your preferred 0:40 way they have open sourced their code 0:42 created a demo and online applications 0:45 for you to try right now if the results 0:47 you've been seeing aren't convincing 0:49 enough just wait until the end of the 0:51 video not only to support my work which 0:53 i'd be grateful for but also because i 0:56 believe it's important to understand how 0:58 it works and its limitations which is 1:00 really interesting as it gives us 1:01 insights into what they are working to 1:04 improve and the following results will 1:06 blow your mind but first allow me to 1:08 come back to last week's video since i 1:10 wanted to share something about this 1:12 episode sponsor weights and biases in 1:15 last week's video which you should 1:16 definitely watch if you haven't yet i 1:19 shared the top 5 articles of the month 1:21 and a great one covered tips from a 1:23 weights and biases user have you ever 1:25 left a long running ml experiment to 1:27 train and had a very sad moment when you 1:30 saw that the training had crashed well 1:32 then you'll love this new feature along 1:35 with tracking your experiments metrics 1:37 now with alerts weight and biases can 1:39 also proactively notify you when things 1:42 go wrong you can be notified via slack 1:44 or email if your training has crashed or 1:46 whether a custom trigger such as your 1:49 loss going to none or a step in your ml 1:51 pipeline has been reached it's really 1:53 easy to set up and you can get started 1:55 with weight and viruses alerts in two 1:57 quick steps turn on alerts in your 1:59 weights and biases user settings create 2:01 your custom triggers and add wnb alert 2:05 to your code wherever you'd like to be 2:07 alerted for a custom trigger and that's 2:09 it i have insights that many users 2:11 already have saved large cloud gpu bills 2:14 by being alerted early to crash runs 2:16 while training large expensive to train 2:19 models which is pretty cool try out 2:22 weights and biases alerts now using the 2:24 first link in the description below 2:29 i mentioned that the model worked well 2:31 on low quality images just look at the 2:34 results and level of detail compared to 2:36 the other approaches these results are 2:39 just incredible note that they do not 2:41 represent the actual image it's 2:43 important to understand that these 2:44 results are just guesses from the model 2:47 guesses that seem pretty damn close to 2:50 our eyes it seems like the same image 2:52 representing the person we couldn't 2:54 guess that the model created more pixels 2:56 without knowing anything else about the 2:59 person so the model tries its best to 3:01 understand what's in the picture fill in 3:04 the gaps or add pixels if the image is 3:06 of low resolution but how does it work 3:09 how can an ai model understand what is 3:12 in the picture and more impressing 3:15 understand what isn't in the picture 3:17 such as what was in the place of the 3:19 scratch well as you will see guns aren't 3:23 dead yet indeed the researchers didn't 3:25 create anything new they simply 3:27 maximized gann's performances by helping 3:29 the network as much as possible and what 3:32 could be better to help a gun 3:34 architecture than using another gun 3:37 their model is called gfp gun for a 3:40 reason gfp stands for generative facial 3:43 prior and i already covered what guns 3:45 are in multiple videos if it sounds like 3:48 another language to you for example a 3:50 model i covered last year for image up 3:52 sampling called pulse uses pre-trained 3:55 guns like style gun 2 from nvidia and 3:58 up-devices the encodings called latent 4:01 code during training to improve the 4:03 reconstruction quality again if this 4:05 doesn't ring any bell please take a few 4:08 minutes to watch the video i made 4:09 covering the pulse model however as they 4:12 state in the paper these methods 4:14 referring to pulse usually produce 4:17 images with low fidelity as the low 4:19 resolution latent codes are insufficient 4:21 to guide the restoration in contrast gfp 4:24 gun does not simply take a pre-trained 4:26 style gun and retrain it to orient the 4:29 encoded information for their task as 4:31 pulse does instead gfpgan uses a 4:34 pre-trained style gun 2 model to orient 4:37 their own generative model at multiple 4:39 scales during the encoding of the image 4:42 down to the latent code and up to 4:44 reconstruction you can see it here where 4:46 we merge the information from our 4:48 current model with the pre-trained gun 4:50 prior using their channel split sft 4:53 method you can find more information 4:55 about how exactly they merge information 4:57 from the two models in the paper linked 4:59 below the pre-trained style gun 2 is our 5:01 prior knowledge in this case as it 5:04 already knows how to process the image 5:06 but for a different task meaning that 5:08 they will help their image restoration 5:10 model better match the features at each 5:12 step using this prior information from a 5:15 powerful pre-trained style gun to model 5:18 known to create meaningful encodings and 5:20 generate accurate pictures this will 5:23 help the model achieve realistic results 5:25 while preserving high fidelity so 5:27 instead of simply orienting the training 5:29 based on the difference between the 5:31 generated fake image and the expected or 5:34 real image using our discriminator model 5:37 from the gun network we will also have 5:40 two metrics for preserving identity and 5:42 facial components these two added 5:45 metrics called losses will help enhance 5:48 facial details and as it says ensure 5:50 that we keep the person's identity or at 5:53 least we do our best to do so the facial 5:56 component loss is basically the same 5:58 thing as the discriminator adversarial 6:00 lust we find in classic guns but focuses 6:03 on important local features of the 6:05 resulting image like the eyes and mouth 6:09 the identity preserving loss uses a 6:12 pre-trained face recognition model to 6:14 capture the most important facial 6:16 features and compare them to the real 6:18 image to see if we still have the same 6:21 person in the generated image and voila 6:24 we get these fantastic image 6:26 reconstruction results using all this 6:28 information from the different classes 6:31 the results shown in this video were all 6:33 produced using the most recent version 6:35 of their model version 1.3 you can see 6:38 that they openly share the weaknesses of 6:40 their approach which is quite cool and 6:43 here i just wanted to come back on 6:44 something i mentioned before which is 6:47 the second weakness have slight change 6:50 on identity indeed this will happen and 6:53 there's nothing we can do about it we 6:55 can limit this shift but we can't be 6:57 sure the reconstructed picture will be 6:59 identical to the original one it is 7:02 simply impossible reconstructing the 7:04 same person from a low definition image 7:06 will mean that we know exactly what the 7:08 person looked like at that time which we 7:11 don't we base ourselves on our knowledge 7:13 of humans and how they typically look to 7:16 make guesses on the blurry picture and 7:18 create hundreds of new pixels the 7:21 resulting image will look just like our 7:23 grandfather if we are lucky enough but 7:25 it may as well look like a complete 7:27 stranger and you need to keep that in 7:29 consideration when you use these kinds 7:31 of models still the results are 7:34 fantastic and remarkably close to 7:36 reality i strongly invite you to play 7:38 with it and create your own id of the 7:40 model and results let me know what you 7:43 think and i hope you enjoyed the video 7:45 before you leave if you are interested 7:47 in ai ethics we will be sending the next 7:49 iteration of our newsletter with 7:51 martina's view on the ethical 7:53 considerations of such techniques in the 7:56 following days stay tuned for that [Music]

An AI that Can Resurrect Memories

Motivation Early on in my Go journey, I was building a billing engine. I needed to handle decimal calculations accurately. Unfortunately, Go does not have a native decimal type. After about an hour of research I found 2 error free solutions. Fast forward to Jan 2021 and a Google search for retrieves the following results: decimal handling in golang In my view, most people who contribute to open source projects are amazing and brave. It takes a lot of courage to put your work and ideas out there. My intention here is not to criticise their work. At the time this post was penned, the library mentioned in the first search result is a poor choice if you want accurate results. There are numerous open issues clearly indicating incorrect results. The second search result has an open issue for incorrect results with very large values. All the other search results are discussing various options to handle decimal operations. The motivation for this post is to discuss 2 error free options with the hope that this post reaches more gophers. Option 1 - https://github.com/cockroachdb/apd is a popular open source DB written in Go. I use it for most of my projects. I was using it for the billing engine I was building and my investigation led me to the library they were maintaining. CockroachDB Here is some example code for decimal division. make sure you are using the latest version of the library - at the time of this post. Note: v2 main ( ) { context := apd.BaseContext.WithPrecision( ) xDecimal, _, err := apd.NewFromString( ) err != {
		log.Fatalln(err)
	} yDecimal := apd.New( , )

	result := apd.New( , )

	_, err = context.Quo(result, xDecimal, yDecimal) err != {
		log.Fatalln(err)
	}

	fmt.Println(result)
} package import "fmt" "log" "github.com/cockroachdb/apd/v2" func main () // Division needs a rounding specified. // Precision here is the total number of digits // to the left and right of the decimal place. 10 // x = 1.234 "1.234" if nil // y = 3 3 0 0 0 if nil Produces the following result: 0.4113333333 Here is some example code based on discussion to control rounding. here main ( ) ( DecimalCtx = &apd.Context{
		Precision: ,
		Rounding:    apd.RoundHalfUp,
		MaxExponent: ,
		MinExponent: , Traps: apd.DefaultTraps &^ apd.InvalidOperation,
	}
) {
	xDecimal, _, _ := apd.NewFromString( ) err := LimitDecimalWidth(xDecimal, , ) err != {
		log.Println(err)
	}
	fmt.Printf( , xDecimal) yDecimal, _, _ := apd.NewFromString( )
	err = LimitDecimalWidth(yDecimal, , ) err != {
		log.Println(err)
	}
	fmt.Printf( , yDecimal)
} { d.Form != apd.Finite || precision <= { } scale < math.MinInt32+ || scale > math.MaxInt32 { errors.New( )
	} scale > precision { fmt.Errorf( , scale, precision)
	} c := DecimalCtx.WithPrecision( (precision))
	c.Traps = apd.InvalidOperation _, err := c.Quantize(d, d, - (scale)); err != { lt v := precision - scale; v { :
			lt = :
			lt = fmt.Sprintf( , v)
		} fmt.Errorf( , precision, scale, lt)
	} } package import "errors" "fmt" "log" "math" "github.com/cockroachdb/apd/v2" var // DecimalCtx is the default context for decimal operations. Any change // in the exponent limits must still guarantee a safe conversion to the // postgres binary decimal format in the wire protocol, which uses an // int16. See pgwire/types.go. 20 2000 -2000 // Don't error on invalid operation, return NaN instead. func main () "14.955" // Max 4 digits to the left and right of decimal place. Max 1 digit to right of decimal place. 4 1 if nil "x= %v\n" // Max 4 digits to the left and right of decimal place. Max 2 digits to right of decimal place. "14.955" 4 2 if nil "y= %v\n" func LimitDecimalWidth (d *apd.Decimal, precision, scale ) int error if 0 return nil // Use +1 here because it is inverted later. if 1 return "out of range" if return "scale (%d) must be between 0 and precision (%d)" // http://www.postgresql.org/docs/9.5/static/datatype-numeric.html // "If the scale of a value to be stored is greater than // the declared scale of the column, the system will round the // value to the specified number of fractional digits. Then, // if the number of digits to the left of the decimal point // exceeds the declared precision minus the declared scale, an // error is raised." uint32 if int32 nil var string switch case 0 "1" default "10^%d" return "value with precision %d, scale %d must round to an absolute value less than %s" return nil Output

x= 15.0
y= 14.96 Option 2 - Use a database Most popular databases have native support for decimal type. If your app involves the use of a database and you need to perform decimal operations on values which are already stored in the DB, then it may be convenient to use SQL to perform decimal operations instead of having to retrieve data and then perform decimal operations in Go. In the event data is not already in the DB, you can construct a SQL statement to perform decimal operations with the understanding that there is a network hop. Example SQL: // PostgreSQL ( :: / :: ):: ( , );

// CockroachDB ( :: / :: ):: ( , ); SELECT '1.234' numeric '3' numeric numeric 20 10 SELECT '1.234' decimal '3' decimal decimal 20 10 Gotchas for Option 1 You will need to spend a couple of hours learning the library. Gotchas for Option 2 A network hop is involved if decimal operations cannot be performed directly on data in the DB. It may pay to spend some time to measure this delay and then assess if option 2 fits your needs for data not already in the DB. The network hop results in a less performant solution when compared to Option 1. Setting up a DB to perform decimal operations will increase cost and complexity if your app does not need a DB. Summary 2 error free options for handling decimal types in Go have been presented. Always prototype new options to measure and understand if they can fit your needs. Trivia Did you know that the co-founder and current CEO of CockroachDB was one of the original authors of the popular tool ? Gimp Disclaimer I am not an employee of CockroachDB.

2 Error-Free Options for Decimal handling in Golang

More than two years ago I wrote the following in : my debut Medium article “My desire with [dotNetify] is to get to a state that can support full-stack micro-service on .NET platform: the ability to have a complex web app composable of independent front+back-end modules that can be worked on and deployed by completely autonomous teams with very minimal downtime” I’m delighted to say that with the release of dotNetify version 3.5, this desire has finally been realized! Little did I know then, I was describing something that only a few months before has made the of things to assess. They call it “micro-frontend”, and for better or worse , that term has entered our (software) industry’s pantheon of buzzwords. ThoughtWorks Technology Radar ThoughtWorks elevated the status to “adopt” earlier this year, which I’m glad they did; not just because it makes me feel a bit vindicated, but because we indeed may have found an effective solution to the problem of sprawling front-end monoliths in enterprise applications. But before I continue with this topic, let me quickly cover my obligatory release announcement. What’s New In v3.5 DotNetify is a free, open-source software that helps you build reactive and real-time web application on .NET Core server. It’s unique MVVM approach puts the view models on the back-end and written in C#, and communicate with the UI layer, either written in React, Vue, or Knockout, on web socket through the SignalR technology (but as you will read next, this has become optional in this latest version.) The most significant update in v3.5 is allowing an SPA to communicate with multiple hub servers. Instead of restricting the client-side views to a single, same-origin SignalR hub server, one can create cross-origin hub proxies and use a new lifecycle hook to switch the connection at runtime. Multi-Hubs The above is accomplished by abstracting the part that communicates with the SignalR hub proxy, which incidentally enables high extensibility. The views are no longer coupled to SignalR, and can use different library or protocols to send / receive data. If you don’t really need real-time push, you can now opt for HTTP Web API by including MVC services to , and setting a flag in the connect options: Web API Mode Startup.cs dotnetify.react.connect( , , { : } }); "MyViewModel" this webApi true What the flag does is making your client-side component connect through a hub proxy implementation that communicates to the server as normal HTTP requests to the dotNetify’s built-in Web API endpoint. This endpoint will instantiate the requested view model, set property values if the client sends them, return the serialized JSON in the response body, and dispose the instance. Switching to the Web API mode won’t require too much change to the way you write the C# view models. You just can’t use real-time functions like or multicasting, and you need to keep it stateless; either let the client script manages the state, or always persist the state to a backing store. Any middleware you write will continue to work, except that the hub context argument that’s used to be populated by SignalR hub context will instead get its values from HTTP context. PushUpdates() One other new hub proxy implementation in this release is the local mode. This mode is primarily meant for unit testing, with which you can set up a mock view model to global as illustrated here: Local Mode window .HelloWorld = {
   onConnect() { { : };
   }
}; { (props) { (props); .vm = dotnetify.react.connect( , ); .state = { : };
   } } window return Greetings 'Hello World' . class MyApp extends React Component constructor super this 'HelloWorld' this this Greetings '' /*...*/ Setting an object with the same name as the view model ID to window will allow you to circumvent the server-side connection and make the component gets the state from that object instead. The rest of new version features is detailed in the . I will now go back to discussing the micro-frontend pattern that this version intends to facilitate. v3.5 release notes Micro-Frontend Overview Micro-frontend is an architectural pattern that decomposes an otherwise monolithic web application into decoupled, independently deployable smaller applications. Each one provides a subset of the UI, usually along a bounded context, which will then be stitched together by a light orchestrator to present a single, cohesive front-end to its users. If you think that it sounds more trouble that it’s worth, then most of the time you will be right! Just with microservices, it’s not for everyone. This technique increases both development and deployment complexities, and introduce a whole new set of challenges. So why is this even a ‘thing’? The answer lies on its ability to effectively address the problems with growing, monolithic front-ends in larger organizations. It’s the same set of reasons that compel them to break their back-ends into microservices: It helps them scale their development process across autonomous, geographically-dispersed teams. It reduces deployment risk when they don’t need to deploy everything in one go. It enables faster delivery of new features or bug fixes, when teams don’t have to wait for one another, or run the entire regression test suite. There are many different techniques people have used to implement micro-frontend. The one recommended with dotNetify is closely aligned to the microservices approach, where aspects of functionality is encapsulated within independent web services (or micro-apps), each with its own build process and deployment pipeline. The domain-driven design approach can be employed on deciding how to slice the problem domain into distinct apps. The diagram below depicts the proposed architecture: The entry to the application is provided by what is referred to as a portal service. This service is responsible for performing front-end orchestration, which involves: discovering app services, loading the static UI script bundles dynamically, instantiating and composing their root UI components into a single-page application with client-side routing (which can be done with dotNetify routing system), and redirecting the network traffic to the appropriate service address. The portal service is also responsible for authentication/authorization. It communicates with an identity provider to generate security tokens, and intercept outgoing service requests to inject the tokens into the request header. In production environment, these services should be put behind an API gateway to secure them and have a single entry point into the system. Micro-Frontend Sample Implementation A simple sample implementation covering the application layer of said architecture is provided in the nuget: DotNetify.React.Template dotnet -i dotnetify.react.template
dotnet mfe -o MyApp new new // To run the app, follow the instructions in README.md Executing the command lines above will create a solution consisting of multiple .NET Core projects, representing apps services and a portal service. The UI are mostly developed with React, with one Vue project added into the mix to illustrate the polyglot nature of this solution. Nginx is used for API gateway, and IdentityServer4 for the identity provider. Each app service is an ASP.NET Core web application, configured to build the UI scripts using Webpack when the application is compiled (dev build on , prod build on ). App Services dotnet run dotnet publish The main UI script that serves as the Webpack’s entry point is made to export a function that will return the root UI component as a native Web Component. This will allow the portal service that will load the app’s UI script bundle to create and mount the app’s root component in a framework-agnostic manner. The following is a sample implementation of the main script. The function is provided by dotNetify-Elements to wrap the React component inside an HTML custom element: createWebComponent { createWebComponent } ; MyApp ; elementName = ;
createWebComponent(MyApp, elementName); () => .createElement(elementName); import from 'dotnetify-elements/web-components/core' import from './components/MyApp' const 'my-app-element' export default document The portal service is also an ASP.NET Core web application combined with Webpack. The UI script contains a function called loader which will be executed as soon as the portal starts. This function is given a list containing information on all the app services, including their addresses. For demo purpose, this list is hardcoded. Portal Service loader(
  [
    { : , : , : , : , : },
    ...
  ], [ , ]
); id 'app1' label 'App 1' routePath 'app1' baseUrl '//localhost:8080/app1' moduleUrl '/dist/app.js' // External dependencies required by the apps. 'dotnetify' 'dotNetifyElements' The loader function will ping each app service addresses, and on getting a response, use SystemJS module loader to load the app, and pass the module function that creates the app's root component to an object that manages and displays these components. { appUrl = app.baseUrl + app.moduleUrl; SystemJS.import(appUrl)
    .then( updatePortal({
        ...app, : .default
    }));
} ( ) function importApp app const return => module rootComponent module When the app’s root component is mounted, it will communicate to its own hub server. Since the address is relative, the portal needs to intercept every connect request and redirect it to the correct address. The portal can do this by implementing and use the special identifier that each app will need to provide when its component makes the connect call to forward the request appropriately: dotnetify.connectHandler apps = ;
dotnetify.connectHandler = { appId = vmConnectArgs.options.appId; app = apps.find( x.id === appId); (app) {
    app.hub = app.hub || dotnetify.createHub(app.baseUrl); {
      ...vmConnectArgs, : app.hub, : { 
         ...vmConnectArgs.options, : { : + getAccessToken()}
      }
    };
  }
}; const /* registered apps */ => vmConnectArgs const const => x if return hub options headers Authorization 'Bearer ' Along with the hub change, it too injects the access token to the connect request. The service’s back-end is set up to get the JWT signing keys from IdentityServer4 to authenticate the token. Finally, the portal uses the to dynamically build and run the client-side routing. Any app that use dotNetify routing system will be able to integrate and nest their routes within the portal's root path. NavMenu component from dotNetify-Elements With each micro-frontend app being developed in isolation and deployed independently, naturally there are concerns over visual inconsistencies, and ballooning size due to duplicated dependencies. This can be mitigated by agreeing to use a shared set of core UI components as basic building blocks for the app’s more domain-specific components. Shared UI Library Some organizations have sufficient resources to build their own UI design system, which usually includes a set of themed stylesheets and a common UI component library.  These modules are always referenced by the apps, but can be declared external when bundling.  Only the portal loads them during its initialization so it can be made available to all apps. The reference implementation uses for this common UI library.  This is a set of specialized UI components designed to work with dotNetify view models and fully support reactive programming model.  It's built with React, but it exposes the same components as HTML custom elements, making them reusable in other non-React frameworks. dotNetify-Elements Summary DotNetify v3.5 brings notable enhancements to support micro-frontend pattern to web applications developed with .NET Core back-end, either with SignalR or with standard HTTP Web API. Detailed documentation can be found on . Please direct further questions or feedback to the . Show support for this project with your stars! dotNetify website github issues forum

Build A React/Vue + .NET Core Micro-frontend with dotNetify

( , and ) recently attended the Techstars Cloud 2015 program in San Antonio, Texas. Since getting accepted late last year, I’ve talked to a lot of people interested in and accelerators in general. I figured it would be a good idea to share our story and some of my thoughts as a CTO. Our company Derek Lenny myself Techstars Techstars You could define as an accelerator for early stage startups. In reality, it’s a lot more than that. Techstars is a family of incredible people who understand more than the Xs and Os of starting a company. Let me elaborate… Techstars Verticals Techstars runs 18 programs world wide, 8 of which are city programs and not focused on a specific vertical. The remaining 10 are vertical programs and accept companies focusing on cloud, , health, education, wearables and more. robotics Having 10 companies in a common vertical is great from an investor’s point of view. If you’re managing a fund and thinking about attending a demo day then it makes more sense to go somewhere and see 10 companies in your space than a generic program that might have 1–2 companies you care about. The investor thing is nice but the real draw for me is the value you give and get from your peers during the program. I loved interacting with all of the companies in the Cloud program. They certainly helped team Knowtify along the way and we’re very grateful for that. The logo for the Techstars Cloud program. Application process Going into the application process, was 9 months old with 3 employees and a functional beta product with a few paying customers. We were living on a small investment from friends and family. Several months earlier we applied for and so we were fairly familiar with accelerator applications. Knowtify YC 500 startups Techstars was far and away a better experience. I’m obviously biased in my assessment but the biggest difference for me was transparency. To kick things off, I had a face to face meeting with , the 2015 Cloud Managing Director, before ever submitting our application. From there, he made himself available by email and Google Hangout for the next few weeks in case we had any questions. That alone made it a better experience. Flying out to San Antonio to meet the team at and pitch our company, took it to the next level. The vibe just felt right. Blake Yeager Geekdom Waiting for a decision was far more tolerable when we didn’t feel left in the dark. The process took about 3–4 weeks. We got a thumbs up from Blake over Google Hangout. It was fitting and just felt great getting accepted into the Techstars family. San Antonio In early January we packed our bags and moved from San Francisco to San Antonio. It’s actually a pretty nice city with a growing tech community thanks to , and . Here are a few of the city highlights and lowlights. Techstars Geekdom Codeup Food wise, I have to say I expected a little more. The BBQ is solid and Texas seems to be the land of burgers…but I didn’t have a great steak on my trip. There aren’t a lot of options for Asian and European food. Southern California Mexican is better than Tex-Mex. Fun fact: Texans don’t seem to be wine drinkers but they do like a good beer. Some of the outdoors eateries had 50+ beers on tap. I even heard tale of a place with over 200! Texans are a lot more patient than Californians. They are also generally very nice and hospitable. No sidewalks or bike lanes! It’s not a great place to be a pedestrian. In San Antonio you don’t have to pay for bags at the grocery store or sort your trash into 3 piles after eating! Living halfway across the country from was by far the worst part of the trip. Everything would have been better with her there. Evy Wilkins Remember the Alamo Brewery! They gave us a free keg of beer every week during the program. Teams , , , , , , , , , and . Appbase Bitfusion Card Isle Callinize Elasticode Fantasmo Studios Knowtify Nebulab Stabilitas VirtKick Showing up in San Antonio on day 1 and meeting the teams was very exciting. The diversity committee was pleased There were teams representing 4 countries Nobody shared an HQ in a common city Only a few of us were post revenue Some founders were fairly young Only 2 repeat founders People came from a variety of backgrounds Surprisingly we had 6 military veteran founders I would have liked to see more… Women founders Founders with a stronger background in UX/Design Older founders (we were mostly all in our 20s/30s) Subu Rama and team Bitfusion scores a point at the Startup Olympics! Cloud Staff Techstars had 6 inspired people working 24/7 to help us build our companies. and ran the show. I certainly couldn’t have chosen a better team. They are organized, smart, creative, assertive and tough but fair. On top of that, they get shit done. Blake Kara , , and were our Hackstars & Associates. They helped companies do everything from redesign and rebrand (including us) to producing content and managing social media. They put in long hours without pay and pulled off some amazing work. Chris Josh Tabitha Erik As token of our thanks, we gave the Hackstars & Associates a pinata at the end of the program. I know that is some insanely skewed compensation for anyone out there counting beans. But at Techstars, we . More on that later. #givefirst Blake’s first program as a Managing Director. Storytelling It’s really the basis for everything you do as an early stage company. A story helps the team develop a clear vision that can be articulated to investors, new employees, customers and the press. Why storytelling? It’s really the basis for everything you do as an early stage company. A story helps the team develop a clear vision that can be articulated to investors, new employees, customers and the press. What’s the Knowtify story? We’re building an engagement marketing platform to help software companies market to their . Our first offering is a full-stack email tool to let marketers design and manage all of their emails from one spot. This includes digest, transactional, behavioral and announcement emails. Once we nail that, we’ll expand into new channels such as SMS, retargeting and in-app messages. existing customers How Knowtify turns a new user into a happy user. Design by Lenny Mentor Madness (1st month) The first month of Techstars is like speed dating for companies and mentors. You talk to as many entrepreneurs as possible from the Techstars network. The goal is to find 3–5 people you like working with to help grow the company over the next 2 months leading up to demo day. I’m sure we easily talked to more than 50 people. Some days we’d talk to 5–7 mentors. Other days we’d only talk to 1–2. In the end we paired up with 4 pretty amazing mentors. , , , . Daniel Feld Paul Ford Dirk Elmendorf Rodney Rice Paul Ford doing his thing. Mentor Month (2nd month) The second month of the program was about spending a few hours per week with each mentor and really cranking away on messaging and the product. This is where our vision really started to come together. Over the first month, it probably took 15–20 minutes to explain what we do. After the 2nd month, we were able to get there in under 1–2 minutes. Being able to explain what you do fast just makes the discussion so much more productive. Instead of people asking questions like… How is Knowtify different from X? You get questions like… Can Knowtify help me accomplish Y? Pitch practice (3rd month) In the 3rd month, the focus is purely on getting ready for demo day. We spent part of the month getting documents ready to share with investors but I’d say most of it was in preparing our demo day pitch. probably practiced pitching our company over 200 times. In the final week I’d say he averaged over 20 pitches per day. Derek Demo day Overall I’d say demo day went well for all of the companies in our batch. Everyone delivered a presentable pitch. A few presenters forgot a minor line or 2 but nothing close to catastrophic. I’m probably biased but and delivered an excellent pitch for . The slides looked great and the story helped paint our vision. I’ll share a video soon if we add it to Youtube. Derek Lenny Knowtify The investor turnout was good. I’d guess around 100 investors attended the event and who knows how many were watching from the sideline. We had some good discussions during the after party. Definitely looking forward to some of the follow up conversations. Demo day introductions. CEO/CTO Dinners Every week either the CEOs or the CTOs got together for dinner. This is a great concept but I didn’t personally get as much out of dinners as I could have. Here’s why: We had dinner in the middle of the week after long days. I often felt mentally exhausted. Dinners often interrupted a coding session and I found it hard to detach from the project and be social. A lot of the venues we chose were loud and crowded. Having said that, I would have preferred to do breakfast with CTOs rather than dinners. That way everyone is rested, it’s a more relaxing environment and people aren’t thinking about finishing a project. But I don’t think other people share my opinion here. It all really depends on your work style. Productivity It is absolutely a challenge to keep pace with your product while a large portion of each day into Techstars. But it is absolutely worth it. What you lose in productivity, you gain in many other areas. investing We focused on contracting instead of hiring during the program to keep things moving. This worked out well for us because we landed a top notch backend engineer and a super creative content marketer. Thanks and ! Joshua McKinney David Smooke went another route. Instead of contracting, they hired 3 junior developers straight out of a coding school called . I was skeptical of the move at the time because making a junior hire requires a lot of upfront time which you don’t really have during the program. But it worked out well for them. Team Stabilitas Codeup Team Stabilitas doubling their team size. #givefirst , one of the founders of Techstars, lives by this wonderful ‘give before you get’ philosophy. The idea is not born out of pure altruism where you give but don’t get. It’s hard to pay bills without the getting side of the equation. What this means is don’t worry as much about being transactional and clearly defining what you get for what you give. Instead, just focus on giving first. If the relationship evolves then getting will follow. Brad Feld This is a great technique we can all use to invest in our business and personal relationships. Not every relationship will pan out. Sometimes you’ll give without getting. That’s ok because the relationships that do work out will be stronger. Events On average 2–3 times per week Blake would bring in an expert from the Techstars network to give a talk on a wide variety of business topics. Sometimes people would talk about fundraising, design, development, marketing or success/failure stories. Some talks were formal and others were very informal. I was a fan of the talks. The quality was great and they added diversity to the program. Only a few of talks featured subpar content or were too promotional in nature. KPIs Every Wednesday night we’d get together and share our company KPIs. Most companies would focus on 2–3 numbers that represent the value customers are getting from their products. This was easily one of my biggest personal take aways from the program. Before, I always thought KPIs were just bullshit vanity metrics companies use to show everyone how great they are. It’s clear that a lot of people use KPIs in this way. But if you focus on the right numbers for the right reasons then KPIs can be a great source of inspiration for the team. Don’t show a number that’s too abstracted away from everyone’s day to day lives. Sure MRR is important but if you’re a developer and you see that number, how does it influence your actions? Instead, focus on a more approachable number you think will impact MRR. Maybe that number is weekly active users. Now it becomes actionable. Team members can take actions with the intention of bringing users back into the app. (email, social…) If you start driving up a KPI but it’s not impacting MRR the way you expect, then you’ve probably made a bad assumption or you’re measuring it wrong. Just reevaluate. KPIs aren’t set in stone. KPIs are no joke. Werewolf Werewolf is the official game of Techstars companies everywhere. At least once per week we’d all get together to drink beer and play this dramatic game of trust and deceit. Feelings were hurt, chairs thrown, alliances forged and broken…we had some serious fun. If you’re a werewolf, don’t be a “me too voter”. Playing coy can work but it’s a strategy too commonly used by the werewolves. Pro tip #1: Talk to your neighbors. If you don’t collaborate, you won’t last long as a villager or a werewolf. Pro tip #2: If you’re playing with a significant other, it might be a good idea not playing as neighbors. I’m sorry of team village. Pro tip #3: Evy Somebody is about to get lynched. Conclusion Techstars was a wonderful experience for me personally and for our company. It wasn’t all chocolate cake and fairy dust but I’d rate it a solid 9.1 out of 10. That is a very high number for me. Once a holiday was declared because I gave something an 8.4. Not because I’m famous or anything…I’m just usually more critical than this post might imply ;) Interested in learning more about , or anything in between? or send me an email at . Techstars Knowtify Follow me on Twitter dane@knowtify.io

Stories, News & Mentions about APPBASEIO

Appbaseio’s Stories on HackerNoon