Apollo 21

apollo21

I originally published this story on the Atlan Humans of Data publication. On July 20, 2019, we complete fifty years since humans officially landed on the moon for the first time in 1969. This historic feat of accomplishment is often synonymous with two names—Neil Armstrong and Buzz Aldrin. That’s not the complete picture. While we celebrate the legendary astronauts who first stepped on the moon, their achievement wouldn’t have been possible without the hard work and dedication of countless others. Here’s the story of the humans of data behind the Apollo 11 mission. 1955-1975: The Space Race In 1957, the Soviets had launched the first satellite, Sputnik. After that, they sent humans to space. The Soviet dogs Belka and Strelka (left); Cosmonauts Valentina Tereshkova and Yuri Gagarin (middle); Cosmonaut Alexei Leonov (right) All that was left was sending the first human to the moon. 1961: A Herculean Task for NASA As the Soviets seemed to be winning the space race, former U.S. President John F. Kennedy issued a challenge to NASA (National Aeronautics and Space Administration). In 1961, President Kennedy set a goal for NASA to “land a man on the moon and return him safely to the earth,” within the next 10 years. The mission seemed impossible as the U.S. didn’t even have a spacecraft to take humans to the moon, a computer compact enough to do the navigation, spacesuits, knowledge of the effects of prolonged weightlessness or space food. They didn’t even know what they would need, and whether humans could even think in zero gravity conditions. 1961-1969: NASA Gets to Work The U.S. poured into the moon landing effort. NASA hired people from different organizations such as Boeing, North American Aviation, McDonnell Douglass, Grumman Corporation, MIT to work on a nationwide project called The Apollo Program. $25.4 billion Managing such a large nationwide team with diverse skills fell onto the shoulders of , now known as “the father of the space shuttle.” George E. Muller George Muller, the Deputy Associate Administrator for Manned Space Flight at NASA, briefs President John F. Kennedy and senior officials. Photo courtesy: NASA He transformed management in NASA by introducing radical approaches. One such approach was the ‘all-up’ testing method that allowed several systems to be designed and developed in parallel, drastically reducing design time. Another approach was to organize personal visits from the NASA astronauts to the factories developing the parts of the Apollo program spacecraft. The visits made the factory workers realize that a single error could kill the man they met, motivating them to devote their lives to Apollo. The Computers of the 1960s A major challenge that NASA faced was building a computer small enough to fit onboard a spacecraft. Even the most compact “minicomputers” were as big as 2-3 refrigerators placed next to each other. Designed by 3C, the DDP 116 was the world’s first commercial 16-bit minicomputer. Photo courtesy: Computer History Museum NASA also had to defy the popular notion that computers weren’t reliable. Back then, computers had a bad reputation as they broke down every few hours. After several years of experimentation to reduce the size of the Apollo spacecraft computer and boost its computing power, the engineers and scientists at MIT and NASA had a major breakthrough. They used the IBM mainframe computers on the ground to make course calculations and feed navigation data to an onboard the spacecraft. The AGC would only perform specific tasks such as guidance, navigation, and spacecraft control. AGC (Apollo Guidance Computer) While the mainframe computers were the size of a car, the AGC was compact, weighing only 70 lbs (approximately 32 kgs) and taking up less than 1 cubic foot of space. The IBM mainframe computers on the ground (left); The AGC onboard the spacecraft (right). Photo courtesy: NASA Another major issue with the computers was the integrity of the memory. There were concerns that the AGC’s memory could be compromised due to a potential Soviet attack. To build a memory that could not be erased, modified or corrupted in any way, MIT used a technique called rope memory, where small iron rings had wires running through them. A wire running through the center of the ring represented ‘1’, whereas a wire that ran outside represented ‘0’. A seamstress weaving the software for the guidance system computer. Photo courtesy: Computer History Museum Over eight weeks, the program was literally weaved into the memory by skilled seamstresses who wove wire-carrying needles through the iron rings, one wire at a time. 1968: Apollo 8 Orbits the Moon A year later, NASA launched Apollo 8—the first crewed spacecraft to leave the Earth’s orbit, reach the Moon, orbit it, and return. Apollo 8 performed 10 circumlunar orbits within 20 hours and safely returned to Earth. Following the success of Apollo 8, on May 18, 1969, NASA launched Apollo 10 as a “dress rehearsal” to the actual lunar expedition. The Apollo 10 crew was tasked with testing all the elements of a moon landing, without actually descending onto the lunar surface. All that was left to do was launching the mission that landed humans on the moon. July 19, 1969: From Earth to the Moon After traveling for 75 hours and 50 minutes, Apollo 11, carrying a crew of three astronauts—Neil Armstrong, Edwin “Buzz” E. Aldrin Jr., and Micheal Collins—finally entered into a lunar orbit. The three-stage 363-foot rocket used its 7.5 million pounds of thrust to propel itself into space. The three-stage rocket that flew humans to the moon. Photo courtesy: NASA Everything was going smoothly and the Lunar Module (LM) “Eagle” was on its way to land on the moon, roughly 46,000 feet away, when things suddenly went awry. With Just 30,000 Feet to Go, the Computer Crashes Minutes before the LM was about to land, the AGC had crashed. The screen went blank. Program alarm. It’s a twelve-oh-two. Give us a reading on the 1202 program alarm. Apollo 11 Commander Neil Armstrong to Mission Control, Houston When the program alarm 1202 flashed on the screen, it sent the astronauts in space as well as the entire Mission Control at Houston into a panic. During their simulations, the astronauts had never come across either of these errors and didn’t know whether to keep going or to abort the mission. Over the next seven and a half minutes, the alarms went off five more times. With the Eagle rapidly descending, a decision had to be made quickly. In Mission Control, mission guidance officer Steve Bales immediately called his colleague Jack Garman, an engineer who sat in a backroom and maintained computer error codes on his console as a cheat sheet. It’s an executive overflow. Jack Garman, a NASA engineer Garman’s reply to Bales gave the astronauts a go ahead. Overloaded with Data, the AGC Does What It Was Built to Do Computers in the 1960s had less computing power than the smartphones of 2019. When the AGC was overloaded with data, it dropped everything else to perform its core function—navigate and guide the astronauts. Dropping the other functions required a system reboot, which is why the AGC flashed the 1202 alarm. With every overload, the AGC dropped more low-priority programs and rebooted to continue navigation and guidance. Mission Control relayed the same to the astronauts in the LM and the mission to moon went on. Jack Garman’s cheat sheet with a list of all Apollo alarm codes. Photo courtesy: Collect Space That’s when a more dangerous problem confronted the astronauts. With Two Minutes to Land (or Crash), Things Go Out of Control As the astronauts were occupied with decoding the program alarms, they overshot the intended landing area in the by several miles. Sea of Tranquility With just 1,500 feet to go, Commander Neil Armstrong finally looked through the window display. That’s when he realized that the Eagle was speeding towards a crater with steep sides. A NASA video shows the difference between simulations on the ground to the actual moon imagery while landing. The spacecraft was also quickly running out of fuel—just 60 seconds of fuel left—and headed towards a deep lunar pit full of boulders bigger than a bus. It was also too late to retarget the AGC for finding a more suitable landing point. That’s when data and years of extensive experience came to the rescue. The Extraordinary Astronauts Calculated the Landing Point Manually I don’t think we breathed for the last minute. Nobody in the room breathed for the last minute. Charlie Mars, a NASA engineer at the Kennedy Space Center With no computer to rely on, Neil Armstrong took manual control of the Eagle and tapped into his experience as a pilot to fly The Eagle like a helicopter. With minutes left and the fuel levels dangerously dropping, he kept his cool and trusted his experience. Buzz Aldrin supported him by continuously monitoring altitude data from the AGC console. Together, they calculated manually the right spot for landing the Eagle without crashing. : Read More Want to see through the moon landing through the eyes of Neil Armstrong and Buzz Aldrin? NASA just released a video that shows the final moments of the moon landing. You can read about it here . July 20, 1969: The Eagle Has Landed Thanks to their calculations and skills, the Apollo 11 astronauts had found the nearest spot to land in the Sea of Tranquility. Houston, Tranquility Base here … the Eagle has landed. Apollo 11 Commander Neil Armstrong The efforts, dedication, and composure of the astronauts in the final moments of the mission was the reason why humans made it to the moon successfully. Without them, the outcome would have been completely different. Neil Armstrong (left), Buzz Aldrin (centre), and Micheal Collins (right). Photo courtesy: NASA The rest, as they say, was history. Neil Armstrong planting the U.S. flag on the moon (left); the Earth as observed from the moon (right). Photo courtesy: NASA July 24, 1969: To the Moon and Back After a flight of 195 hours, 18 minutes, 35 seconds, the Apollo 11 mission successfully returned to Earth and safely splashed down in the Pacific Ocean. NASA had kept its promise to the late President Kennedy with still a few months to spare. The Apollo 11 crew landing in the Pacific Ocean. Photo courtesy: NASA Humans of Data Behind Apollo 11’s Success The moon landing was a success due to the efforts of over 400,000 people from several organizations nationwide, working tirelessly. From engineers, scientists and technicians who built the spacecraft to the incredible astronauts who landed Apollo 11 on the moon, humans of data were there at every step of the way. Thanks to their efforts and dedication, we were able to finally set foot on the moon.

How Data Got Us To The Moon

If you were to ask anyone whether they preferred the original Ace Attorney trilogy or the Apollo Justice trilogy, there’s a very good chance they would say the former. The first 3 games were so amazing that they were extremely hard to follow up. However, the Apollo Justice games (which consist of Ace Attorney 4,5, and 6) are still very good games, and I would encourage anyone who hasn’t played them yet to stop reading this article immediately and play them this instant. They’re filled to the brim with interesting cases, villains, and brand-new protagonists such as Athena Cykes and, of course, Apollo Justice himself. So today, I’m doing the near-impossible and choosing the top 5 Apollo Justice cases. Warning: Spoilers Ahead. The 5 Best Cases From the Apollo Justice Trilogy 5. Turnabout for Tomorrow 5-5 4. Turnabout Revolution 6-5 3. Turnabout Trump 4-1 2. Turnabout Succession 4-4 1. Turnabout Storyteller 6-4 5. Turnabout for Tomorrow 5-5 Throughout the fifth game, Dual Destinies, we know that something traumatic happened to newcomer Athena Cykes. She was keeping a big secret, and in Turnabout for Tomorrow, everything gets revealed. Cykes’ past, prosecutor Simon Blackquill’s connection to all of it, and the mysterious murderer of 2 people all come to light. Turnabout for Tomorrow is the final case of Dual Destinies, and it serves as a fitting end that ties up all the loose ends in a neat bow. The case also has an incredibly shocking twist that I did not see coming. 4. Turnabout Revolution 6-5 Speaking of wrapping things up and shocking twists, the last case in Spirit of Justice brings that in spades. The final case in every Ace Attorney game always goes hard, but probably none so than Turnabout Revolution. It’s long with twist after twist that you don’t see coming, and just when you think you have it figured out, they throw another twist at you. But apart from the craziness of the case, another reason why Turnabout Revolution is great is because it provides closure for Apollo Justice. The once very nervous rookie defense attorney is finally allowed to spread his wings and become a new and improved man. 3. Turnabout Trump 4-1 Shocking twists are usually reserved for the end of the game, but in Apollo Justice, they come out swinging with them. Apollo and his mentor, Kristoph Gavin, have to defend this strange, disheveled man who is accused of murder. Little does Apollo know that their client is the former Ace Attorney himself, Phoenix Wright. And if that wasn’t crazy enough, it turns out that the real murderer was helping us all along. That’s right, in the end, our friend and mentor Gavin is revealed to be the mastermind behind the murder. Apollo Justice has one of the strongest starts in the history of the series, and that’s why it’s one of the best cases in the Apollo Justice trilogy. 2. Turnabout Succession 4-4 When we meet Phoenix Wright at the beginning of the game, we know that he’s not the same man that we last saw in Trials and Tribulations. He lost his reputation, and most importantly, he lost his job as a defense attorney; he was disbarred. But we didn’t really know what happened until Turnabout Succession when everything was revealed. But not only do we see what happened, we experience it ourselves. We play as Phoenix Wright during his last trial when he’s framed for forging evidence, we find out who was behind it all, and we see Apollo Justice rise to the occasion in the present day. And events that we had no idea were important finally make their connections known. For example, the events and characters in cases 4-1 and 4-2 are revealed to actually be a huge part of the story, and it retroactively makes those cases that much better. 1. Turnabout Storyteller 6-4 I love the final cases in Ace Attorney games because it is the culmination of the overall story that they plant from the very beginning. However, I love Turnabout Storyteller for the exact opposite reason. This case has Athena Cykes defending a young man with the help of prosecutor Simon Blackquill. Case 6-4 has nothing to do with the overarching story, none of these characters will probably appear again in future installments, and in the grand scheme of things that were currently going on in the Ace Attorney world, it didn’t seem that big or urgent. But that’s what’s so great about it. The judicial system didn’t ride on the outcome of the case, nor did an entire kingdom’s future hang in the balance. It’s a simple story about young up-and-comer Athena trying to clear somebody of murder, without the help of Phoenix Wright or Apollo Justice. It’s just her, Widget, and Blackquill. And it turned out to be amazing. It’s relatively obvious who the killer is from the get-go, but I didn’t care. The story and the characters were intriguing, and best of all, the chemistry between Athena and Blackquill was amazing. Athena, the ambitious and eager student vs Blackquill as the reluctant but helpful mentor. This case is so good that it’s by far my favorite in the Apollo Justice trilogy, and I think this single case proves that Athena Cykes is an interesting character enough to warrant her being the star of her own game. Read More: The New Tomb Raider Games in Order Persona 3 Remake Officially Announced: Everything We Know So Far The Kingsman Movies in Order Also published here Feature image source

The Apollo Justice Trilogy: The 5 Best Cases

GraphQL is the alternative for REST made by Facebook. When facebook reached the limits of REST API, they had to make something breaking these limits. Through this article, you can learn what GraphQL is, how it works, and how to use it in your projects. GraphQL (Graph Query Language) is an API-level query language. Like SQL is used for requests to relational databases, GraphQL allows clients to request data from an API. For a good understanding of this article, you should have a basic understanding of TypeScript and NodeJS. Why is GraphQL so good? Receive only data you need. GraphQL allows you to manage what data API will return to you. This has a number of advantages. It helps network performance when the response contains a lot of data you don't need. Of course, REST can handle it via request parameters like , however much easier when it is available by default, does it? It is also useful if your API supports different types of clients which want to call less and fetch more. ?fields=name,birthdate Access to a complex graph of objects aggregated from different sources. GraphQL allows you to get a complex graph of objects by a single request. These objects might be from different sources. Clients and server API schemes are always in sync. Your clients and server have the same scheme, so it is easy to sync it. GraphQL anatomy To understand how GraphQL realizes all you’ve read above, let’s talk about what artifacts GraphQL includes. GraphQL includes schema, which describes the types of objects you can operate on. Take a look at the following schema: type App {
   id: ID!
   name: String!
} This is the type App, which includes id and name required fields. It means you can operate this object. But how to operate it? There are a few access operators in GraphQL. The first one (required one) - . This is a getter for your object. The second one - , is a setter. And the last one is a , which allows you to subscribe for updates of your type. query mutation subscription type Query {
   apps: [App!]!
   app(id: ID!): App!
}
 
type Mutation {
   createApp(app: AppInput!): App!
   updateApp(appId: ID!, app: AppInput!): App!
}
 
input AppInput {
   name: String!
   publisherId: ID!
}
 
type Subscription {
   appMutated: AppMutationPayload!
}
 
type AppMutationPayload {
   mutation: MutationType!
   node: App!
}
 
enum MutationType {
   CREATED
   UPDATED
   DELETED
} The code snippet above contains . Inputs allow you to define input parameters types. input AppInput Another important component of GraphQL - resolvers. Resolvers define how to handle queries, mutations, and subscribers. We will come back to it soon. Apollo Apollo Server is a Node.js implementation of graphQL server. There is good scalable architecture and a strong community that means it is a good choice for use. We won’t talk much about Apollo architecture, we’ll learn everything needed by code examples. Install dependencies "dependencies": {
   "apollo-datasource": "^0.8.0",
   "apollo-server": "^2.22.1",
   "graphql": "^15.5.0"
 },
 "devDependencies": {
   "@types/graphql": "^14.5.0",
   "@types/node": "^14.14.37",
   "ts-node": "^9.1.1",
   "typescript": "^4.2.3"
 } - allows implementing GraphQL server - allows implementing data sources (like database aggregators or rest api integrations) - graphQL package. Required by Apollo. apollo-server apollo-datasource graphql Server Initialization import {ApolloServer, gql} from 'apollo-server'
import {typeDefs} from './graphql/typedefs'
import {resolvers} from './graphql/resolvers'
import {dataSources} from './datasources'
 
const server = new ApolloServer({
 typeDefs: gql`
   ${typeDefs}
 `,
 resolvers,
 dataSources
})
 
server.listen().then(({url}) => {
 console.log(`Server ready at ${url}`)
}) Let’s understand the code above. We are initializing Apollo Server with several arguments. - this is a path for graphQL schema - as a said earlier, we will come back for that a bit later - data sources like DB aggregators and API integrations typeDefs resolvers dataSources DataSources import { AppService } from './app-service';
 
export const dataSources = () => ({
   appService: new AppService()
}); This is DI of dataSources. This format is required by Apollo. import { DataSource } from 'apollo-datasource';
 
export class AppService extends DataSource {
   constructor() {
       super();
   }
} dataSource might look like this. This is an aggregator, where you can implement business logic and accessors for data. Resolvers Finally, let’s talk about resolvers. As I said earlier, resolvers define how to handle queries, mutations, and subscribers. Take a  look at that: type Mutation {
   createApp(app: AppInput!): App!
   updateApp(appId: ID!, app: AppInput!): App!
}
 
type Subscription {
   appMutated: AppMutationPayload!
}
 
type AppMutationPayload {
   mutation: MutationType!
   node: App!
} And now take a look at the resolver: import { pubsub } from '../pubsub';
 
const APP_MUTATED = 'appMutated';
 
export default {
   Query: {
       apps(parent, args, {dataSources}) {
           return dataSources.appService.getApps();
       },
       app(parent, args, {dataSources}) {
           return dataSources.appService.getApp(args.id);
       }
   },
 
   Mutation: {
       async createApp(parent, args, {dataSources}) {
           const { publisherId, ...rest } = args.app;
           let app = await dataSources.appService.createApp({...rest}, publisherId);
           pubsub.publish(APP_MUTATED, {
               appMutated: {
                   mutation: 'CREATED',
                   node: app
               }
           });
           return app;
       },
       async updateApp(parent, args, {dataSources}) {
           const { publisherId, ...rest } = args.app;
           let updatedApp = await dataSources.appService.updateApp(args.appId, {...rest}, publisherId);
           publishAppUpdated(updatedApp);
           return updatedApp;
       },
       async setAppDevelopers(parent, args, {dataSources}) {
           let updatedApp = await dataSources.appService.setAppDevelopers(args.appId, args.developerIds)
           publishAppUpdated(updatedApp);
           return updatedApp;
       }
   },
 
   Subscription: {
       appMutated: {
           subscribe: () => pubsub.asyncIterator(APP_MUTATED)
       }
   },
};
 
function publishAppUpdated(app) {
   pubsub.publish(APP_MUTATED, {
       appMutated: {
           mutation: 'UPDATED',
           node: app
       }
   });
   return app;
} This resolver totally defines all queries, mutations, and subscribers. And as you can see, we have access to data sources that were injected into ApolloServer. let app = await dataSources.appService.createApp({...rest} We deal with this, but what about subscribers? Subscription: {
    appMutated: {
        subscribe: () => pubsub.asyncIterator(APP_MUTATED)
    }
} And what is the code in mutations? pubsub.publish(APP_MUTATED, {
   appMutated: {
     mutation: 'CREATED',
        node: app
     }
}); This is pubSub. Maybe you know this pattern. Microservices usually communicate using it. This is required for subscribers in Apollo. And it makes sense because subscribers are WebSockets. Websockets keep connections, so it is easy to reach a high load. So, the Apollo team decided to handle it with this design solution. Anyway, there is an in-memory dummy, just for testing. Never use it in production. import { PubSub } from 'apollo-server';
 
export const pubsub = new PubSub(); How to test Run the app using the following command: ts-node src/index.ts Go to localhost:4000 via web browser and see the following: This is the test console Apollo. You can test queries, mutations, and subscriptions here. Congratulations! You’ve just learned how to build graphQL API using Apollo and Node.JS. Full code example you can find here: https://github.com/gandronchik/graphql-example

Intro Guide to the GraphQL API using Node.JS and Apollo

Cryptocurrency projects have become a major target for malicious actors intent on disrupting legitimate blockchain initiatives' progress. Apollo Fintech is no exception to this rule, as it and its CEO Stephen McCullah have been subjected to relentless attacks from two notorious figures in the crypto space: Sultan Kassam and Danny De Hek. In this article, we will look at these individuals and their activities concerning Apollo Fintech, explore the detrimental effects of their actions on the project, and provide suggestions on how you can help prevent future attacks against other legitimate crypto projects. An Honest Look at the Individuals Targeting Apollo Fintech and its Partners Sultan Kassam is a British entrepreneur who runs several companies in the United Kingdom. He is also well known for his pseudonyms (e.g., Apollofintechcryptonews) which he uses to spread false and misleading information about Apollo Fintech and its partners. Kassam has been accused of blackmailing multiple businesses associated with Apollo Fintech and its CEO, Stephen McCullah. He's active on Telegram, where he posts lies and threats against the project. Danny De Hek is another person who actively targets Apollo Fintech and its partners. His YouTube channel is highly popular amongst viewers, who enjoy his approach to crypto investment advice. Unfortunately, De Hek often uses and scare tactics to dissuade potential investors from investing in projects like Apollo Fintech. This is a dangerous practice, as it could potentially harm the industry by preventing legitimate crypto projects from succeeding. ill-informed opinions An Overview of The Detrimental Effects of Their Actions on Crypto Projects The malicious actions of Sultan Kassam and Danny De Hek have had a devastating impact on the progress of legitimate cryptocurrency projects, including Apollo Fintech and its CEO Stephen McCullah. Through their lies, threats, and intimidation tactics, they have sought to disrupt the advancement of these initiatives to benefit themselves financially, or at least that is what one can imagine. Why would someone go out of their way to spread false and misleading information about a project if they weren't trying to benefit from it somehow? Furthermore, the activities of these individuals have had an extremely damaging effect on the credibility of cryptocurrency projects. This is especially true regarding potential investors, who may be scared away by the negative publicity generated by these malicious actors. How You Can Help Prevent Future Attacks on Legitimate Crypto Projects In light of the information presented above, it is clear that more needs to be done to protect cryptocurrency projects from malicious actors like Sultan Kassam and Danny De Hek. One way you can help prevent future attacks is by raising awareness of the issue so that potential investors can make informed decisions about where to invest their money. You should also be wary of any advice given by Danny De Hek on his YouTube channel or other social media platforms, as it could be biased and misleading. His followers should exercise caution when considering his advice and do their research before investing in any project. Finally, if you see any false or misleading information being spread about Apollo Fintech or its partners, please take action and report it to the appropriate authorities. This can help prevent future attacks against legitimate blockchain initiatives and ensure they can succeed without interference from malicious actors. Where Do We Go from Here? The actions of Sultan Kassam and Danny De Hek have had a significant impact on the progress of legitimate cryptocurrency projects. Still, it is important to remember that they are only two individuals in a much larger ecosystem. In order to ensure that such malicious activities do not happen again, we must continue to raise awareness so that potential investors are aware of the risks associated with investing in cryptocurrency projects. We must also continue to hold these malicious actors accountable for their actions and remain vigilant in reporting any false or misleading information about legitimate blockchain initiatives.

Uncovering the Dark Truth Behind De Hek and Kassam - Liars Targeting Apollo Fintech

Movie and TV show streaming app ApolloTV has shut down following threats from the Alliance for Creativity and Entertainment. The global anti-piracy coalition hand-delivered a cease-and-desist notice to the developer behind the software, the terms of which he immediately complied with. While third-party Kodi addons remain popular with those seeking free access to premium video, standalone apps for Android and iOS have gained traction in recent years. Easy to install and use on set-top boxes, tablets and phones, these tools often provide a Popcorn-Time or Showbox-like experience, offering the latest movies and TV shows in a familiar Netflix-style interface. On the one hand, they’re popular with users but Hollywood studios and other content creators consider them a risk to their business that needs to be countered. ApolloTV is a relatively recent addition to the growing market. Available for iOS and Android, the application gained a reasonable following and is featured in dozens of tutorials and YouTube video installation guides. At the time of writing, however, it seems highly unlikely that the project will continue. Over the past several days, rumors began to circulate that ApolloTV would be shutting down. The whispers suggested that the application’s developer had been targeted by copyright holders and as a result, the app would be discontinued. Counter-rumors suggested that the developer simply wanted a way out so TorrentFreak approached ‘Sam’ directly to find out. “I received a cease and desist from the Alliance 4 Creativity – the same people who took down Openload and Streamango – citing ApolloTV making available copyrighted works copied and hosted by unaffiliated third parties without permission from the copyright holder,” Sam informs us. The claim seems reasonable given the circumstances. ApolloTV didn’t host any content of its own but did provide access to content hosted on third-party file-hosting platforms, a common feature among similar ‘scraper’-type applications. As TF discovered, Sam made little to no effort to hide his identity so it appears that ACE had few difficulties tracking him down. However, while we reached him easily via email, ACE managed to discover his home address which enabled them to serve the cease-and-desist notice by hand. “I was surprised that I actually received the cease and desist physically, in person (it was delivered by a court officer), at my home address,” he explains. Sam says that he doesn’t have the time or the resources to fight a lawsuit and since ACE were very reasonable, he’ll be complying with their requests immediately. He doesn’t want to go into too many additional details but says that as part of the settlement, he will need to shut down the project’s Github page and hand over the Apollo domain to ACE. At the time of writing, the official ApolloTV repository on Github has been taken down. ACE nor the MPA appear to have filed any official DMCA takedown requests with the developer platform so at this point things seem to be progressing quickly on a voluntary basis. TorrentFreak sought comment from ACE on the reported action but, at the time of publishing, we were yet to receive a response. ACE responded and a spokesperson provided the following comment on the ApolloTV case: Update: “As part of the Alliance for Creativity and Entertainment (ACE) ongoing efforts to protect the legal market for creative content and reduce piracy, ACE representatives contacted an individual in the United Kingdom suspected to be involved with the development, operation, and distribution of an illegal video streaming application.” Originally published as “ ApolloTV Streaming App Shuts Down Following ACE Cease-and-Desist Notice ” with the Attribution-NonCommercial 3.0 Unported (CC BY-NC 3.0) license

ApolloTV Streaming App Shuts Down Following ACE Cease-and-Desist Notice

One of my side projects involves writing a around the Universal Chess Interface ( ). I originally developed a mock implementation and . That used version one of Apollo’s client/server stack, which . One of the biggest changes was the subscriptions interface and implementation, and I struggled for many hours to get that to work. Part of the problem is that the documentation is not very complete and rather scattered. This post will cover the most basic implementation of subscription service and the client code that uses it. GraphQL API UCI wrote about it awhile back changed quite a bit in version two Getting started The GraphQL server will be based on , which in this case will use an Express server as middleware. Subscriptions will use a that is attached to a plain HTTP server (also managed by ApolloServer, as we shall see). ApolloServer WebSocket There are two clients: the , and a client for use by Mocha to test the API outside of a GUI. For simplicity, I’ll keep the Mocha client code in the same folder as the server code. I also use Babel so I don’t have to think about and the like. GraphQL Playground Michael Jackson Scripts With that in mind, here are the packages to be installed: apollo-link, apollo-link-http, apollo-link-ws, apollo-server-express babel-cli, babel-core, babel-preset-env graphql, graphql-tools subscriptions-transport-ws mocha, chai I’ll provide a link to a working code repository at the end of this article. The Server The server is as basic as I could make it: express ; { ApolloServer } ; http ; { typeDefs } ; resolvers ; PORT = ; app = express(); server = ApolloServer({
  typeDefs,
  resolvers,
});

server.applyMiddleware({
  app
}); httpServer = http.createServer(app);
server.installSubscriptionHandlers(httpServer);

httpServer.listen({ : PORT }, () => { .log( ); .log( );
}); import from 'express' import from 'apollo-server-express' import from 'http' import from './schema' import from './resolvers' const 3031 const const new const port console `🚀 Server ready at http://localhost: ` ${PORT} ${server.graphqlPath} console `🚀 Subscriptions ready at ws://localhost: ` ${PORT} ${server.subscriptionsPath} An ApolloServer is created with schema and resolver parameters. The call passes in an express application instance. Finally, an HTTP server is created to handle the web socket interface to the subscription service. Both GraphQL and the subscription websocket share the same port, but under different protocols. applyMiddleware The Schema { makeExecutableSchema } ; resolvers ; typeDefs = [ ,
]; options = {
  typeDefs,
  resolvers,
}; executableSchema = makeExecutableSchema(options); executableSchema; { typeDefs }; import from 'graphql-tools' import from './resolvers' const `
  type Query {
    go: String!
  }
  type Subscription {
    info: String!
  }
` const const export default export The schema is very basic: will return a string acknowledgment, but behind the scenes it will fire off a method that sends publish notifications to subscribers. Subscribers subscribe through the subscription API. go info We can see how this works in resolvers.js: { PubSub } ; pubsub = PubSub(); TOPIC = ; infos = [ , , , ] publish = {
    setTimeout( infos.forEach( pubsub.publish(TOPIC, {info})), )
} { : { : { publish(); }
    }, : { : { : pubsub.asyncIterator([TOPIC]),
      },
    },
  }; import from 'apollo-server-express' const new const 'infoTopic' const 'info1' 'info2' 'info3' 'done' const => () => () => info 1000 export default Query go => () return 'going' Subscription info subscribe => () I’ve made the resolvers deliberately simple. For example, the asyncIterator method from PubSub is quite sophisticated (it supports filters and authentication, for example). Since it is already , I won’t delve into various options here. All the resolver above does is to publish an to all subscribers, passing objects as the body of the subscription. well-documented infoTopic info The Client As I mentioned, I’ll use two clients for testing. One is the built-in Prisma Playground, a service automatically provided by the ApolloServer (FYI: ). you can turn this feature off in production Testing in Playground To test, I’ll open Playground in Chrome, at Within Playground you can open up multiple tabs. For the first, I’ll subscribe to the : http://localhost:3031/graphql. infoTopic When this command is played, you will see a ‘Listening …’ response in the right pane, as shown above. Now you’re subscribed. Open another tab within Playground and query go: This sends back a response of “going”, so everything is okay. Now, going back to the subscription tab, you will see the published output: Testing using Mocha/Chai There’s a lot of boilerplate in setting up a client, so I’ve created a utility file to handle query and subscribe operations. It’s called fetch.js: fetch ; { execute, makePromise } ; { WebSocketLink } ; { SubscriptionClient } ; ws ; { HttpLink } ; gql ; uri = ; wsUri = ; link = HttpLink({ uri, fetch }); wsClient = SubscriptionClient(wsUri, { : }, ws); wsLink = WebSocketLink(wsClient); doQuery = { operation = { : gql ,
  }; .log( ) makePromise(execute(link, operation));
}; subscribe = { operation = { : gql ,
  }; execute(wsLink, operation).subscribe(handlers);
}; doQuery; { subscribe }; /* eslint-env mocha */ /* eslint-disable import/no-extraneous-dependencies */ // see https://www.apollographql.com/docs/link/index.html#standalone import from 'node-fetch' import from 'apollo-link' import from 'apollo-link-ws' import from 'subscriptions-transport-ws' import from 'ws' import from 'apollo-link-http' import from 'graphql-tag' const `http://localhost:3031/graphql` const `ws://localhost:3031/graphql` const new const new reconnect true const new const ( ) => query const query ` ` ${query} console `$query is ` ${query} return const ( ) => query, handlers const query ` ` ${query} return export default export The fetch.js code pulls in a lot of interdependent modules. For the test operations, I use to handle the interface between the server (which has to be running, btw 😉) and the GraphQL operations used by the tests. There are actually two interfaces here: one to handle query and mutation requests vis HTTP, and another that goes through a web socket to subscribe to a topic. apollo-link Most of this comes from the , but you will have to install a few additional modules I neglected to mention earlier: documentation node-fetch (installed globally via ) npm -g ws gql The module implements the HTTP that’s becoming a standard. The module is a WebSocket implementation for Node (there are others), and is a template literal tag that you can read more about . node-fetch Fetch API ws gql here The test itself is pretty straightforward: we first , then : subscribe go chai ; fetch, { subscribe } ;

chai.should();

describe( , { .timeout( ); handlers = { : { .log( , data); (data.data.info === ) { .log( )
        process.exit( );
      }
    }, : .error( ),
  }; it( , () => { query = ;
    subscribe(query, handlers);
  });

  it( , (done) => { query = ; { res = ( fetch(query)).data;
      res.should.have.property( )
      res.go.should.equal( )
    } (e) { .error(e)
      done(e)
    }
  })

}) /* eslint-env mocha */ import from 'chai' import from './fetch' 'subscribe, then go' ( ) function this 5000 const next ( ) => data console `received data:` if 'done' console 'exiting...' 0 error => error console `received error ` ${error} // get the subscriber ready... 'subscribe' async const `subscription {
          info
        }` 'go' async const `query {
            go
        }` try const await 'go' 'going' catch console The object (passed to the method) is what receives the publish notifications. When the last published message is received, the test process is terminated. hander subscribe Conclusion You should explore the links provided, as there is a lot more about GraphQL subscriptions that I wasn’t able to cover in this article. I’ve also included a few relevant links, below. A complete github repository containing the code above can be found . Enjoy! here Tutorial: GraphQL Subscriptions (server-side) — Apollo GraphQL apollographql/graphql-subscriptions: A small module that implements GraphQL subscriptions for Node.js SSL on Apollo Server 2.0 + Subscriptions · Issue #1338 · apollographql/apollo-server apollo-link-ws | Apollo Link Composable networking for GraphQL | Apollo Link Apollo Client | Apollo Client

GraphQL Subscriptions Using Apollo 2

In software development you'll hear the term "moon shot". If something is a "moon shot" it's something that's extraordinarily difficult, like landing on the moon. We say this about some app doing something cool, but what about the software that... landed us on the moon? What was the original "moon shot" all about? The Software That Put Us on the Moon Meet . She was the director of Software engineering at MIT Instrumentation Laboratory, which was contracted to build the onboard software for the Apollo Space Program. This is her standing with the stack of source code used to launch us to the moon. Today we complain when Visual Studio runs slow. Margaret Hamilton If you're a developer of any kind, you owe a lot of thanks to her, since "Software Engineer" wasn't even a term before she came along. So imagine having to write software that had to work the first time it ran, and run perfectly, or people would die. Sounds like a lot of pressure right? Margaret and her team did it. They built it, and it worked. It succeeded. They made a piece of machinery land on the moon with a computer that had about .08 percent of the processing power of an iPhone. You can get a lot more . background and details here The Source Code A few years ago, Ron Burkey released . He put a ton of work into this. This is the source code for the Apollo Guidance Computer, or AGC. the source code for Apollo 11 Not only can you download the source code, but he created a simulator for the AGC, at the . You can dig deep into the systems and how they work, trust me it's a rabbit hole for geeks. Tons of awesome stuff here. There's even a you can check out to get familiar. Virtual AGC Page kinder, gentler introduction to the AGC The AGC source code is written in assembler, which is foreign to most of us. I've played around enough with x86 assembler to know it's not my calling, but perusing through a lot of this source code, you can piece together how some of this stuff works. Comanche and Luminary If you dig into the code, you'll see it's divided into two parts, Comanche and Luminary. Comanche is the software for the and Luminary is the . Command Module Lunar Module The was the cone that contained the crew and vital equipment, and was the vessel returned back to earth. Command Module The well, it was the module that landed on the moon. Lunar Module It's very interesting to see how these systems interact. When you look through the source code you can see a lot of cool hints how everything works. The DSKY The DSKY was the user interface for the computer. You could enter commands through a calculator-like interface and it was connected directly to the AGC. The commands contained a and a for each command. verb noun If you dig deep enough into the source code you'll see a lot of references to the DSKY and commands related to it. It was a marvel of engineering for its time. Of course, there is a if you want to play around. DSKY simulator How Do I Know so Much About This? I may sound like a seasoned expert here, but I just took this on the code of the Apollo 11, then started digging in the code and researching stuff. free course Click Here to Take This Course for FREE For the 50th anniversary of the Apollo 11 Moon Landing, Simon Allardice created this awesome course on Pluralsight exploring the AGC. It's a quick course, and it won't teach you how to write AGC specific assembler code, but it will give you a good idea of how things worked back then and how the whole thing fits together. After watching this you'll get a better understanding of the source code, and start looking for easter eggs. Conclusion Ok if you're a nerd like me, you love stuff like this. Obviously this isn't some kind of actively developed code where you can do pull requests and add features. Nobody will hire you because you put AGC knowledge on your resume. But it sure is fun to go through this code and figure out how things worked, and look at the comical comments in the code. It's fascinating and well worth the time to explore if you're genuinely curious about this kind of stuff. You can always if you'd like to discuss it further. yell at me on Twitter Enjoy!

The Course and Source Code for the Apollo 11 Guidance Computer (AGC)

I first wrote a version of this article just over 16 months ago, and it’s pretty impressive how much the GraphQL community has achieved in that time. First of all, the question is no longer Apollo or Relay, but rather Apollo or does one even need a fancy client at all. If you’re just testing the waters with GraphQL and don’t want to change your existing app too much, you can just use in your component like so: really fetch fetch('/graphql', {  method: 'POST',  headers: {    'Content-Type': 'application/json',    'Accept': 'application/json',  },  body: JSON.stringify({query: "{ hello }"})})  .then(r => r.json())  .then(data => console.log('data returned:', data)); The main benefit to adopting a GraphQL client is the cache implementation. Using fetch is fine to begin with, but you don’t want to be using it in an app where users quickly jump between views. In we use Apollo to cache query results — which gives us quite a noticeable boost in performance. How it works in practice: OnlineOrNot User opens a list of their GraphQL applications -> this list gets cached User opens a list of tests -> client has already fetched data about the applications, so it adds the tests to each application User now visits their list of applications again -> no new GraphQL request is made, all results are already in memory Essentially, the more the user clicks around your application, the faster your user experience becomes. On Bundle size One of the biggest complaints I hear about adopting Apollo is the bundle size (Apollo Boost, the “easiest way to get started with Apollo Client” weighs in at 30.7 kB min+gzipped), so luckily there are also alternative lightweight clients to consider: No article on GraphQL clients would be complete without mentioning . Though Amplify does take an ‘everything but the kitchen sink’ approach to features, and you get included with it: AWS Amplify everything Authentication Analytics API GraphQL Client Storage Push Notifications Interactions PubSub Internationalization Cache Thus Amplify may not suit your needs unless you’re building a whole product experience that relies on GraphQL and don’t want to customise your approach. Why I like Apollo Client The setup is considerably easier than Relay — it involves installing one package, and adding the to the root of your React tree. ApolloProvider The API is nice — they have an equivalent to Relay’s QueryRenderer called that does what it says: Query <Query    query={gql`      {        rates(currency: "USD") {          currency          rate        }      }    `}  >    {({ loading, error, data }) => {      if (loading) return <p>Loading...</p>;      if (error) return <p>Error :(</p>;      return data.rates.map(({ currency, rate }) => (        <div key={currency}>          <p>{`${currency}: ${rate}`}</p>        </div>      ));    }}  </Query> It can be used to manage state in your React app — that is, you can directly write to Apollo’s Redux-like store and consume that data in another part of the React tree. Though with React’s new Context API, and React’s best practices of you probably won’t need it. Lifting State Up import React from 'react';import { ApolloConsumer } from 'react-apollo';import Link from './Link';const FilterLink = ({ filter, children }) => (  <ApolloConsumer>    {client => (      <Link        onClick={() => client.writeData({ data: { visibilityFilter: filter } })}      >        {children}      </Link>    )}  </ApolloConsumer>); Downsides to Apollo It’s huge. It weighs in at 10x more than the smallest GraphQL client I’d consider using, and 3x more than urql Quirks Apollo is not without quirks however: Since Apollo uses to build its cache, forgetting to include in your query can cause some interesting bugs and error messages id id Why I dislike Relay Setup The main benefit to using Relay is that doesn't get included in your frontend bundle, saving your user from downloading the whole GraphQL parser - it "pre-compiles" the GraphQL queries at build time. relay-compiler What annoys me about Relay is that it requires a fair bit of work to even add to a project. Just to get it running on the client side, you need to: add a relay plugin to your config .babelrc set up relay-compiler as a yarn script setup a “relay environment” (essentially your own utility to pass data to the relay-runtime), and fetch add components to the React Components you wish to pass your data to QueryRenderer On the server side, you need to: Ensure the IDs your app returns are unique across all of your types (meaning you can’t return nice ID values like , they need to be like ) 1, 2, 3 typename_1, typename_2 Developer Experience The developer experience itself is pretty unpleasant too — needs to run each time you modify any GraphQL query, or modify the schema. In large frontend teams this means teaching everyone to run every time you change branches in Git, since almost all of our work involves fetching data from GraphQL in some way. relay-compiler relay-compiler Quirks Being one of Facebook’s Open Source projects doesn’t necessarily mean issues get fixed quickly. Occasionally, things break in unexpected ways: Using an old version of graphql breaks : relay https://github.com/facebook/relay/issues/2428 Errors don’t get sent via the error object in GraphQL when using QueryRenderer, instead one needs to create an type, and send the errors through the data object: error https://github.com/facebook/relay/issues/1913 Originally published at onlineornot.com on December 15, 2018.

Apollo vs Relay Modern: Which GraphQL Client to consider using in 2019

In this article, we’re going to use Apollo Server and get started without any extra dependency. We will have to pick the folder structure for our project and we’ll be exploring three different ones alongside their pros and cons. Structuring your code is probably the first task you will have to do when starting a new project. Of course, if you’re using a framework, you will probably get offered a default structure. This is because “convention over configuration” principle generally helps to get started a lot faster. However, when writing micro/small services in Node.js, I find frameworks too bloated because they come with many things that we either don’t need (ex: routing) or that we will swap with another lib at some point (ex: security). It’s also great to get to the basics to start your new app without the bloat and to handpick every dependency that we’re going to add. This way, if we’re writing multiple services with the same libraries, we come up with our own kind of framework that is perfectly suited for us. What a beautiful thing! is often paired with the web server but also include its own production-ready server (which is just a spin of Node’s ). This is perfect for us, considering we can add a different web server like express or koa if we need it later. However, starting vanilla also means we are faced with no enforced patterns to structure our code. To the inexperienced developer, this can be daunting. How are we going to decide the structure of our code? Well, sweat no more, we’re going to explore three different architectures so we can pick the best one for us. Apollo Server express http.Server In this article, every example comes from the Github repository where we can find a working application implementing each structure. betaflag/graphql-server-scaffolding From that repo, the only dependencies are Apollo Server and GraphQL. npm install apollo-server graphql The minimalist This structure reflects the pure architectural simplicity of writing a server in a single file. Of course, this is unsuitable for large projects, but I can justify its usage in a micro or small service. First of all, not all APIs require a lot of code for their server. Consider this example: you want to integrate sentiment analysis to your messages in your chat application. You decided that this shouldn’t be part of your core application and should be externalized into a separate service. It would act as a black box: a message comes in, an analysis comes out. You can start working right away with an open source library called “Sentiment” that gives you this simple interface “ ”. Writing your sentiment analysis micro service will only require to wrap it inside a resolver and would fit nicely into a single file. sentiment.analyse(message) .├── package.json└── src└── index.js Pros You get an instant overview of all the code of the API You can get started instantly It’s easy to refactor and to evolve into a more structured app as you adapt your app to real-world usage. Cons Only suitable to small applications otherwise it can get messy really fast It will probably evolve into another structure at some point It might be hard to collaborate with other devs if everyone’s working on the same file. The role player This is what you usually get when creating or scaffolding a project using a framework. It’s an easy structure to get started and fits applications of all sizes. This structure is about putting files where they belong according to their respective role. The GraphQL type definitions are found in the “ ” folder, and the resolvers are located in the (you guessed it) “ ” folder. typeDefs resolvers Here’s an inexhaustive list of roles you can find in a GraphQL API: data, models, migrations, validators, typeDefs, resolvers, services, routes, config, utilities, etc. .├── package.json└── src├── data│   └── index.js├── models│   ├── Book.js│   └── index.js├── resolvers│   ├── booksResolvers.js│   └── index.js└── typeDefs├── index.js├── query.js└── types├── bookType.js└── index.js Extracted from on Github betaflag/graphql-server-scaffolding Pros: Fit all kinds and all sizes of applications Newcomers can get around easily Each file represent a single concern like a class or an object Cons: As the app grows, those top-level directories become messy This architecture is not modular and might evolve into a monolith Overkill for very small apps The domain expert If you want to add an extra modular touch to your app, this structure is for you. In this structure, the top-level folders represent domain areas. It is modular because of the natural boundaries between these. We can even achieve extreme modularity by externalizing domains into their own NPM modules that could then be shared across applications. However, it’s not because you can that it always makes sense to do it. Defining your domain isn’t always easy when starting a new application. Domains like users, permissions and profiles are quite natural, however, you will probably have some overlapping sub-domain at some point and this is where it gets difficult. On the other hand, it’s great to separate your domain with a clean interface and to decide once and for all where a sub-domain lives. In large applications, teams generally form organically around domain areas. Think of data, reporting, security, etc. .├── package.json└── src├── books│   ├── Book.js│   ├── data.js│   ├── index.js│   ├── resolvers.js│   └── typeDef.js└── index.js Pros: Modular; a domain can be externalized in its own module Scalable; this structure adapt quite well to very large apps Clean; forcing a sub-domain into a parent make sure there is no overlap Cons Also overkill for smaller apps Conflict can arise for establishing ownership of sub-domains (however resolving them is a really good thing) Domain boundaries might not be clear from the start Conclusion Choosing the right structure for you is your choice and it’s always possible to change it later. However, choosing the right one from the start is a good way to avoid future headaches. If you know other structures that I haven’t covered, I’m looking for help to add them to my repository at . You can also add it in the comments below. Discuss with me on Twitter betaflag/graphql-server-scaffolding @betaflag Photo by on Nicolas I. Unsplash

Three ways to structure your GraphQL code with Apollo Server

This time around I’m going to refocus back on the Apollon project where I am a member of the team. management If you want to know more about Apollon you can read about the project and the people behind it in my article — . Apollon — Masternodes for the Masses But for the purposes of this article I am going to assume the reader is already familiar with the Apollon platform and project. OK what’s this NodeVault thing all about then? When Apollon released the Nodebuilder they did so without the one of the components they had been developing called the ‘Nodemonitor’. They did this to release the platform as soon as possible due to demand from their community and people who were excited to use the platform. tool Since then people who follow me on , or follow the Apollon Twitter feed ( ), will have noticed the team have been working on adding extra projects/coins to the platform at a furious rate. However during September the team decided it was time to also refocus efforts on putting in place a monitoring tool for the Apollon platform. Twitter https://twitter.com/apollonxap It was a member of the Apollon community (Jeian on Discord) who brought the potential solution to this challenge to the Apollon teams attention. Thanks Jeian! The team took a look at the solution in question, loved it, and felt there was definitely an opportunity here to be explored to provide both parties exactly what they needed to move forwards. Yeah great…. So who, or what, is it?…. As you have probably guessed by the title of this piece the solution was a mobile Masternode monitoring app - released only a few weeks previous called NodeVault. Following discussions between the NodeVault and Apollon teams a way forward was identified to support the NodeVault app by allowing the app to utilise elements of the Apollon infrastructure and at the same time implement functionality within the NodeBuilder and NodeVault to make adding nodes to the monitoring tool as simple and efficient as possible for Apollon customers. Wow! Sounds great. OK how do I get hold of it and use it? OK, first off, you’ll need to sign up to the Apollon NodeBuilder software, register an account and setup your nodes on the platform — you can download the NodeBuilder here - https://apollon.one Next, you’ll need to download the NodeVault app either on iOS or Android. The links to the relevant AppStore and Google Play stores pages are below: AppStore — https://itunes.apple.com/gb/app/nodevault-masternodes/id1434304882?mt=8 Google Play — https://play.google.com/store/apps/details?id=com.nodevault Adding your Apollon NodeBuilder nodes to the app is as simple as scanning a QR code. That is all there is to it! It’s that simple! Within the NodeBuilder platform Apollon has added a new button to the Deployments page of the software: QR code button within the Nodebuidler Clicking this button will generate a QR code which, when scanned within the NodeVault app, will auto-add all NodeVault supported nodes to the app. In addition when you deploy a brand new node a QR code will be generated at the end of the process to allow that specific node to be added. Not all nodes hosted on Apollon are available in NodeVault but Nicolas (we’ll meet Nicolas in a moment), the NodeVault developer, will be adding the rest of the Apollon supported nodes as soon as humanly possible. Using the scanner in the app is also very simple and intuitive. Simply open the app and click the menu button on the top left of the screen. It will bring this side menu up: NodeVault side menu Once here all you do is click on ‘Link your Apollon Nodes’ and the QR scanner opens. Point this at the QR code from the NodeBuilder and Hey Presto! all your supported nodes are added just like magic…. well sort of… Now I’ve added my nodes what do I get? Once added and making sure you have push notifications switched on you will get alerts sent direct to your mobile device when certain states change on the node being monitored. These are when your node starts up, goes offline or when you receive a new reward on your Masternode. In addition when you click on one of your monitored Masternodes you will be given key information such as Daily, Monthly and Yearly estimated rewards (note for most masternodes these change during block reward step changes). In addition you can also see when the node was last paid, last seen (or went offline) and how long it has been active as per the screenshot below: And a final screen you can access within the app, within the currencies page, shows you all the supported coins on the app. Clicking on one of these will provide even more information on a specific currency such as price action, block rewards structure, number of nodes in the network and other key information: Currency detail screen within NodeVault If you’d like to see a video of the Apollon CEO (Chad Sichello) juggling a phone whilst demonstrating the app then please view the link below: https://youtu.be/0kR1okWOvjQ OK I think that’s probably enough of me prattling on about the app and what you can do with it. Next I’d like to introduce you the mind behind NodeVault — Nicolas Meienberger. What is your name and how long have you been involved in the Cryptocurrency space? My name is Nicolas and I’m currently living in Switzerland. I remember that I discovered cryptocurrencies during a talk at school in late 2012. At that time I didn’t give it much more attention. I really started to dig deeper, like many other people, during 2017. This is when I realized what the potential of Cryptocurrencies could be. How did you get into Cryptocurrencies, Masternodes and why? As a developer it’s always exciting to discover new technologies. I didn’t get involved as an « investor » but rather as an « experimenter ». I’ve developed several apps on the Bitcoin testnet, Ethereum smart contracts and even a homemade Bitcoin ATM (which isn’t working at all). I discovered Masternodes through a friend which was making good side revenues and I immediately wanted to learn more about them. Tell us a bit more about NodeVault, why did you launch the service and why it’s different from the other monitoring services out there? Nowadays, the main device for browsing the internet has become the mobile phone. Having a native mobile app for any service is always a better experience for the end-user. This is why I launched NodeVault. I want to give users the best experience possible to monitor their masternodes as easily as possible. What is your role in the project and what is your background? My role in the project is simply everything. I created NodeVault from A to Z with love and passion ! I’m a professional fullstack mobile developer since 3 years and I’m happy to collaborate with Apollon to push the project further ! Where do you think the Masternode market will be in 6 months, 12 months and in 24 months time? Currently the Masternode market is not at a good place. It’s flooded everyday by scam coins with unbelievable ROIs and the bear market doesn’t help. But I really have trust in this technology and I’m convinced that it will explode in a near future. With all those services like Apollon and NodeVault it’s now so much easier to enter the Masternode world than it was 1 year ago. In the short term I hope to see the process of running a Masternode become even less painful . This will bring a lot of new investors since the passive income is really attractive. Trust me, we have some bright days ahead ! What does the future hold for NodeVault and what are your future plans to develop the service further? I really want to push NodeVault way further in the future. I have tons of other ideas to implement like shared masternodes and in-app ssh commands. My objective is to totally hide the technical aspect of Masternodes to the user. And there you go — I’m sure you can see just from reading the snippets above what a pleasure it is for the Apollon team to be working with NodeVault and Nicolas. His enthusiasm is infectious! If you want to find out more about the NodeVault platform or ask questions of Nicolas you can do so within his Discord channel at: https://discord.gg/jq3AxAP For updates for when my next article lands or just general Masternodes updates, advice and guidance follow me on Twitter at https://twitter.com/Ade_Redman Until next time. Happy noding! Ade

Stories, News & Mentions about APOLLO21

Apollo21’s Stories on HackerNoon